Adguard VPN causes Android 9 Meizu phone on Cellular connection to reboot as soon as VPN is connected.

[luk77]

Hi,
I saw some threads about phones rebooting when using AdGuard with Android 10, but this happens to me on Flyme 7.3.1.0G which is based on Android 9.
I narrowed it down to Adguard VPN and it only happens on cellular connections, not on WIFI. I even tried updating to AdGuard Beta 3.3RC1, didn't help at all.
I had an older Meizu phone(now broken) using Flyme 5 and had no problems with AdGuard's VPN mode. Now AdGuard is pretty much useless for me because it doesn't block ads on Cellular networks and I don't usually use my phone outside of my house.

In summary, steps to reproduce:
1. Enable Adguard VPN
2. Disable WIFI, but enable Cellular Data(3G/4G)
3. Phone goes into reboot

Details:
Phone: Meizu 16Xs
Android version: 9
Build number: Flyme 7.3.1.0G
Adguard version: 3.3 RC1 from Beta channel(same thing happens with latest stable version)

 

[Boo Berry]

Does it happen again if you do the reverse and while using AG for Android and mobile data is enabled and then you enable WiFi and it connects to it? Does it reboot again?

If so, I have a similar issue with my current device, and Andrey looked into it for me a couple months ago and found it's probably caused by a bug in the device's firmware (and my device's firmware hasn't been updated yet, so I'm stuck with it). The only way I workaround it is to pause AG for Android's protection when switching from WiFi to mobile data or mobile data to WiFi and re-enable AG for Android's protection it once it's connected. I also have to disable autostart for AG for Android as with an unstable WiFi/mobile data connection it can cause reboot loops.

 

[luk77]

For me it doesn't matter what the order is. Device reboots as soon as there is a pair of mobile data + ag(vpn).

 

[Boo Berry]

Yes, but does it also reboot when you're connected to mobile data, then you connect to WiFi? Does it happen after connecting to WiFi?

 

[luk77]

There is such a small time window for me to do it that I'm not sure phone even managed to connect to WiFi. There's like 1 or 2 seconds after AG+Mobile data are enabled before phone reboots, but I just tried that and yes it still goes into reboot.

 

[Chinaski]

Hello, Gentlemen!

As it was rightly noticed this problem seems to be related to the peculiarities of the firmware, so to find out for sure you need to do the following:
- AdGuard > Settings > Advanced > Logging Level > Record All.
- Reproduce your issue.
- Note the time the error occurred and let us know.
- Don't forget to return to the default logging level.
- Logs can be sent to me at PM or on devteam@adguard.com

 

[Boo Berry]

Yeah, Andrey told me to update firmware if I can back in July when I asked him about it, which I can't because there's no updated firmware. In my case, I'm probably stuck until there is a firmware update (well, if there ever is...), or until a root exploit is found and I can root my device and use the local HTTP proxy instead.

I do have several ideas for AG for Android that could potentially workaround this via a low level setting... auto pause protection when switching the data connection from WiFi to mobile data or vice versa to try to prevent the reboot. Yes, one of these ideas could force the user (aka me) to manually unpause/resume protection, because I think it trying to auto-resume protection once the connection switches likely triggers the issue. Or at least some sort of delay in place when switching data from WiFi to mobile data or vice versa, e.g. wait one minute until after the device has established a stable data connection before resuming protection in AG for Android. Think of it this way, I can workaround the issue if I pause AG's protection before I switch from WiFi to mobile data then switch the connection, then unpause AG for Android's protection when the mobile data connection is up and running. Then I have to repeat it; pause AG for Android, enable WiFi and wait for the connection to establish, then unpause AG for Android's protection and all is well again.

Basically, my ideas for low level settings are like this...

1) Auto-pause protection when switching data connection (WiFi and/or mobile data)
This would allow AG for Android to automatically pause the moment WiFi or mobile data is disconnected while the device is trying to establish a new connection to either mobile data or WiFi. This should workaround the top main source of the reboots.

2) Auto-pause protection when data connection is lost
This would pause AG for Android's protection while there is no data connection at all (no WiFi or mobile data), because this too can cause a reboot (and reboot loop if you have AG for Android set to autostart with an unstable connection). This should hopefully be able to workaround one of the other main sources of the reboots, the loss of all connections.

3) Resume protection from pause delay
This would allow the user (aka me) to set an amount of time before AG for Android automatically will unpause and resume protection IF there's a stable data connection (either WiFi or mobile data). Like for example I'd set this to two minutes, so AG for Android can detect if there's a stable connection and wait the two minutes before resuming protection. Now this could be amended further to allow a negative value for this setting, which would require the user (again aka me) to manually unpause AG for Android and resume filtering (so AG for Android won't try to automatically resume protection), if the reboot issue still occurs.

 

[Boo Berry]

Talking to several developers in the Telegram channel, looks like my ideas above won't make any difference (as trying to detect the connection state isn't fast enough, and by the time it can it's too late), as it's a bug in the Android's Linux kernel that'd require the device manufacturer to release an update for. Apparently Chinese phone manufacturers haven't bothered to update their kernel in their devices with this issue fixed.

So, there's only real two ways around this...

1) Get a new phone that's not from a Chinese manufacturer since they never update their kernels.

2) Manually pause AG for Android when you're going to switch from WiFi to mobile data (or vice versa). Also disable autostart in AG for Android, to prevent any sort of reboot loop if you're encountering an unstable connection that drops multiple times. Doing this, I very rarely encounter the issue anymore, only during times of unstable WiFi (which is also rare).

Otherwise, it looks very likely that there's nothing that can be done about it and no workarounds in the app itself are possible. The only hope is if the manufacturer decides to push an OTA update with a newer kernel with the fix... which honestly, I wouldn't hold my breath on.

 

[luk77]

@Chinaski hello! Thanks for the reply.
I couldn't export logs through "Export logs and system info" because of an error "An unexpected error occurred while exporting log files".
I've reproduced the rebooting issue with "Logging Level: Report Everything" at 23:00 or 23:01 MSK time. My "Automatic crash reporting" setting is ON. Not sure if it helps.

Note: tried exporting logs on 3.3RC1 in Beta and later on 3.3 on Release channels.

 

[Boo Berry]

If it's the same issue I have (which I'm pretty sure it is) there's nothing AG or any app developers can do about it to fix it. The only way to fix it is hope your phone vendor releases an OTA update with a fixed kernel.

 

[luk77]

@Chinaski can I provide any other information? Still can't export the logs due to "unexpected error".

 

[Chinaski]

As Boo Berry rightly noticed, it looks like all these problems are related to the firmware of your device.
And unfortunately, nothing can be done here.

 

[luk77]

FYI for people who stumbled upon this thread: 3.4 nightly 9 completely fixed this problem for me.

I've noticed a partial fix in 3.4 nightly 8 where reboot didn't happen on network change, but my phone rebooted when I got a call while on cellular network with Adguard running. This isn't happening with 3.4 nightly 9.

Big thanks to developers who fixed this.

 

[Boo Berry]

Wow, you're right, it's not rebooting on network changes anymore for me either, YAY!