patcon
commented
9 years ago Ah, hadn't made a connection to orwall, but i also see lots of app error popups on boot. Also assumed it was orbot. I have lots of apps going through orwall as well
Closed cyl-us closed 9 years ago
patcon
commented
9 years ago Ah, hadn't made a connection to orwall, but i also see lots of app error popups on boot. Also assumed it was orbot. I have lots of apps going through orwall as well
cjeanneret
commented
9 years ago Hello,
how many apps do you have allowed in orwall? As it will (currently) loop for each app and set each iptable rule one by one, this might slow the device at boot time (or when you re-enable orwall).
Regarding boot up apps being locked:
orwall locks all network connection first (via the init-script), meaning no application can access the network. Once orwall boots up, it will initialize iptables in such a way it allows first orbot, then loops through the authorized apps and apply the correct rules.
Those two steps aren't easy to remove, unless the init-script embeds orwall rules for all apps (meaning we'll need to generate it each time we update allowed application list).
Regarding apps uninstalling: orwall is notified by the system once an app is removed so that it:
It doesn't block app cleanup nor removal or, at least, not on the four devices I own and use for tests (nexus4 with lates CM, nexus7 with latest SlimKat and old HP Slate 7 with latest stock ROM).
Hence, I see the following possibilities:
I might find a way to push start-up rules as one command, this might allow a smoother startup…
Not really easy to spot anyway :/.
cyl-us
commented
9 years ago I understand that no application can access the network during startup, but applications that don't even try to access the network are completely prevented from starting. If the device is only slowed at boot, maybe I just need to be patient. I'll try setting off the issue again and let the device sit for an hour to see if it clears up on its own.
It looks like I only have one gigabyte of RAM and a 1.4 gigahertz processor. It's hard to upgrade to a newer device, because the lack of source code in the stock systems makes them untrustable. I use an older device because it supports Replicant (a CyanogenMod fork with full source code available).
It looks like I have nineteen applications run through orWall. I don't need all of them all the time, I can add and remove them from orWall as needed.
UPDATE: It seems the hour didn't help, so it either takes longer than an hour for the device to fully start up with this many applications passed through orWall or it doesn't finish starting at all. It's also worth noting that if orWall is given a short list at boot time and all the other applications are added after the device starts, the process is very quick. Boot time is normal, and each added application seems to be added instantaneously.
cjeanneret
commented
9 years ago Hello!
Thanks for the update. So it seems indeed orWall bootup is eating the capabilities of your device. "Nice", and I couldn't really spot that, even on the (apparently not so) crappy slate7.
I'll try to find a better way for orwall boot, either queuing rules or by merging all the rules in one big command. Queuing will be easier and cleaner, but might not correct the whole problem.
Stay tuned, new release might be out shortly (but in any cases after 31c3, as I'm there and away from my dev desktop ;) )
cyl-us
commented
9 years ago The bizarre part is that there is such a fine line between when it works and when it doesn't. It either starts up with almost no delay or it doesn't seem to start up fully at all. There's never an in-between. It also only seems to take a few applications being removed from the access list to put things back in the green again. Quite frankly, I don't understand what could be going wrong.
Thanks for your help and for maintaining such a great application! It's nice to have a way to deny network access to applications that request it but don't really need it.
cjeanneret
commented
9 years ago :) seems android is pretty picky some times. I'll try to queue the rulea instead of applying them synchronous, I'm pretty sure it will help, as it will let android manage the different processes.
There will be a downside though: it's possible the rule application will take a bit longer. But that's for the better.
cjeanneret
commented
9 years ago Hello,
Just in order to get a deeper check: what happens if you disable, wait a bit, then re-enable orWall (home screen, first switch)? Does it also "explode"?
Purpose of the question: enabling orWall calls the same method as boot time. If it doesn't bork your device network, this means there's "something else" somewhere between the boot process and the rules application.
Thanks in advance for your feedback! Oh and, happy new year ;).
cyl-us
commented
9 years ago Sorry for the delay, the email alerting me to your comment got burried in a sudden wave of spam.
Stopping orWall (version 1.0.4) and restarting it a bit latter does not cause the problem, as the problem is that the device is prevented from fully initiating. (I think. It seems that some core components such as the uninstalled, the component that calculates application storage space, and some other things are prevented from starting.) Once everything is running, orWall doesn't shut everything down or retroactively stop it from having started.
The new update you tweeted about today (version 1.0.5) likewise doesn't have the issue at all. I gave Internet access to every application orWall allows me to, including all the ones that I don't want actually accessing the Internet, which probably about tripples the ammount of checked applications. There was some slowness at first after rebooting, but the device booted normally and everything is working.
cjeanneret
commented
9 years ago \o/ wooohooo! So the queuing seems to work as expected.
My explanation: Boot process is really heavy, with many threads/processes. Android can multi-process, but there are some limits. The fact orwall looped through all the configured apps and, for each, runs a command "in the loop" probably ate too many "frames", locking out the others apps. Now that there's a queue (well, not really a queue but something alike), the system might delay a bit the command application, in order to let other apps/boot process have access to the resources.
I guess I can close the issue now? :)
patcon
commented
9 years ago :heart:
I thought it was Orbot doing it at first, due to Orbot being more prone to failure in the past, but upon further experimentation, it seems to be orWall doing this.
I had my superuser application set to grant orWall root access automatically without prompting me. This has worked quite well until recently (probably at the last update, but I wasn't paying attention at the time), but now, if orWall is granted root access, I often lose my ability to install/uninstall applications, clear application data, and even open most of my applications. Many applications fail to autostart as well, including Orbot, SMSsync, and Weather Notification (all available on F-Droid). The (AOSP, I think) calendar home screen widget also often fails to load, and the device becomes very slow to respond.
I find that whenever orWall is not granted root access, much less fails, and I am able to clear orWall's data or uninstall orWall, either of which fixes the rest of the problems.
If you know how I can provide you with more specific information, I'd be happy to tell more. OrWall is one of my must-have applications, so I'd love to see this resolved.
UPDATE: It seems that the issue only occurs when many applications are given Internet access. When only a few are checked in orWall, there isn't any problem. It seems the probability of seeing the issue goes up as you add more applications to the approved list. Are IP tables stored in RAM or something? It's also important to note that this issue usually is seen right after the device boots, though sometimes happens later.