resolutecake

The cause of this is a race condition in the app in Log new view, entries appear as Unknown(-100) in Log old view, entries appear as AppID: -1, App Name:...

Here’s a script that helped me out: can be placed at /data/script and added to AFWall+ as custom script ./data/script ``` #!/system/bin/sh # License: ISC # /data/data/com.termux/files/usr/bin/nano /data/tether # hotspot...

@ukanth This is THE BUG TO FIX for 3.6 random blocking of initial packets is not a problem when communication is retried but it is a problem for DNS privacy,...

@ukanth Log Symptoms: The problem is packets being associated with App ID -1 Unknown, which in new log appears as -100 — victim apps are Android Connectivity Check and OpenVPN...

I do not know your specific cases, but if applying rules fails for any reason, such as the buggy parallelism in 3.5.3, then AFWall+ blocks almost everything. This is shown...

Additionally, due to AFWall+ 3.6 design, initial packets may be delayed by up to 15 s due to temporary blocking of vpn and dns while AFWall+ is working. Because AFWall+...

This works on all my Androids The requirements on AFWall+ to avoid — up to 15 s network outages caused by AFWall+ and — temporary DNS failures and permanent failure...

The app has several bugs, I am running my own branch The -w1 -W1 is a code change in the app that I diagnosed and completed. Once the right answer...

And you must use Active Rules or there is no VPN control (note: if Active Rule is unselected checkbox settings in LAN and VPN are lost) If you only want...

The fix for AFWall+ bad state is to Apply Rules again If you want it disabled, first enable then disable Unless the last shown thing was a toaster “Rules applied...