Afwall+ not working on dependably on marshmallow with different root method

[mddvul22]

I've got a nexus 6 running omnirom 6.0.1 that was rooted differently than Chainfire's method. I'm using an opensource root method, detailed here: http://forum.xda-developers.com/nexus-6/general/root-t3231211

Afwall+ installs correctly. I'm able to enable/disable firewall rules, and things work for a while. However, after some time passes, things start to malfunction. For example, apps that are allowed wifi access can no longer access the internet. If I disable Afwall+ and then reenable it, the app's internet access starts working again. This is happening with multiple apps.

I'm not sure if this is an Afwall+ issue, or a marshmallow issue, or something related to the root method I've used (but my other apps that require root are working fine).

Please let me know if I can offer any assistance.
Thanks.

[ukanth]

Can you send error report(under firewall rules) or iptables log when your applications starts behaving differently?

I observed this behavior even in Lollipop 5.1.1.

[mddvul22]

Just emailed the error report, iptables.log, and description/reference to this ticket. (Please disregard the first error report, sent approximately an hour earlier, where I neglected to attach the iptables.log and also neglected to reference this ticket.

[ukanth]

Looks like busybox needs to be updated (built-in). @78c59635bdd8 , please install busybox installer and change the settings within afwall ?

Also please disable log service and observe the behavior.

Are you using restrict background service for any apps ?

[chrsigg]

To add another data point: I have the same or a similar issue with a Nexus 5, running stock 6.0.1 and rooted using SuperSU v2.61. AFWall works well initially, but after some time connections are becoming blocked even though they have the proper permissions set in the GUI. Disabling and re-enabling the firewall temporarily fixes the problem, until it happens again.

[AlexanderOMara]

I'm also noticing this issue. I'm not sure as I haven't observed it long enough, but it might be related to switching networks? Any updates on this issue?

[ikelos]

I suspect it's due to doze mode, and afwall+ being asleep when the network changes (so that when it's woken up, it doesn't spot the change in time and so doesn't update). I seem to have had a much better time (although still need to wait a little bit after a network change) once I disabled battery optimizations on afwall+. This can be altered under Settings > Battery [Menu] Battery Optimization > All Apps > Afwall+ > Don't optimize.

I'm not entirely sure why the rules need changing in between every network state change. It looks as though the rules are all specific to the medium they're using (wifi, mobile, roaming, etc), so perhaps this could be improved? It was also interesting to see that marshmallow appears to have its own firewall manager (but luckily the two seem to be able to coexist peacefully)..

[AlexanderOMara]

If it helps, on my end it seems I have to first disable rules, close the app, re-open the app, then enable rules to make it work again. Just disabling then re-enabling does not seem to work.

[chrsigg]

Yes, but for me this is only a temporary fix.

Are there still things that need to be done for 6.0.1 support? I understand that this is a volunteer effort and the devs are of course free to work according to their own schedule.

But with the recent serious vulnerabilities and Google's monthly patch schedule, running the latest release is a must IMO.

On Jan 29, 2016 11:26 PM, AlexanderOMara notifications@github.com wrote:

If it helps, on my end it seems I have to first disable rules, close the app, re-open the app, then enable rules to make it work again.

—
Reply to this email directly or view it on GitHub.

[ikelos]

Please could you try disabling battery optimizations for afwall+ and seeing if that helps?

[ikelos]

It's not quite clear what you mean by "busybox is not available". Using busybox from stericson's busybox installer appears to work just fine?

NetGuard has a lot of plus points but prevents use of an actual VPN whilst it's blocking apps.

The battery optimization of the afwall+ app absolutely is involved in afwall+ (not just the gov. of M). The FAQ for NetGuard (point 21) even tells you to do the same thing (which is what made me try it for afwall+). The thought is that broadcast receivers may be inhibited in doze mode (such as the connectivity change receiver that afwall+ uses in "Active Rules" mode).

Having set battery optimization mode to off for afwall+ specifically I've found that a few seconds after joining a WiFi network, the firewall service has been restarted, a toast appears letting me know that the change in network occurred and my appropriate rules appear to be applied. It's entirely possible this is just masking the issue (by having afwall+ carry out a complete service restart), rather than actually fixing it, but in order to get any more information we need people to test it and report back a) whether it worked and b) if there were any changes/consequences from doing so.

[chrsigg]

I deactivated battery optimisation and will see if it has a positive effect.

On 30 Jan 2016, at 16:26, CHEF-KOCH notifications@github.com wrote:

Maybe we just whitelist it via REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission but imho it's not an good option because in the case someone not want to enable the monitoring option in AFWall then this would be bad, my suggestion is to remove the monitoring option within AFW (and enable it by default) and add this permission because a firewall must be run all the time and of course the monitoring option is essential in case network mode changed, but I do agree on Wifi/VPN (as I already said) we may add a whitelist to not monitor the status to safe a little bit energy by ignoring it's state.

—
Reply to this email directly or view it on GitHub.

[AlexanderOMara]

Just wanted to report back, I haven't had the issue since disabling battery optimizations back when it was suggested above.

[chrsigg]

Same here. Thanks for the suggestion.

On Feb 18, 2016 8:23 AM, AlexanderOMara notifications@github.com wrote:

Just wanted to report back, I haven't had the issue since disabling battery optimizations back when it was suggested above.

—
Reply to this email directly or view it on GitHub.

[AlexanderOMara]

With the latest updates, I have disabled the setting to disable battery optimizations, and have not experienced the issue again since. I believe this issue is resolved.