Describe the bug
The way AFWall 3.6 works is that on an interface change, all rules are deleted and then rebuilt
— However, all necessary information for all control-column connection types is always available
— Therefore, one set of rules should be implemented for each column and be configured in iptables ahead of time
— When a different interface is activated, AFWall+ can simply switch sets with a single iptables command, instead of hundreds, and avoid rebuilding command strings and re-execute logic on each highly time-sensitive network-configuration change
This would eliminate several execution race conditions in 3.6 that breaks vpn and Private DNS and even regular DNS
It would also eliminate the experience of 4-second network blocks on switching an interface
One such pre-configured chain-set can be better optimized than today’s single-set for all columns
For good architecture, the code should build an in-memory structure that is then applied to iptables
Describe the bug The way AFWall 3.6 works is that on an interface change, all rules are deleted and then rebuilt — However, all necessary information for all control-column connection types is always available — Therefore, one set of rules should be implemented for each column and be configured in iptables ahead of time — When a different interface is activated, AFWall+ can simply switch sets with a single iptables command, instead of hundreds, and avoid rebuilding command strings and re-execute logic on each highly time-sensitive network-configuration change
This would eliminate several execution race conditions in 3.6 that breaks vpn and Private DNS and even regular DNS It would also eliminate the experience of 4-second network blocks on switching an interface One such pre-configured chain-set can be better optimized than today’s single-set for all columns For good architecture, the code should build an in-memory structure that is then applied to iptables