[FEATURE] - delay for auto tunnel

[Scrounger]

Is your feature request related to a problem? Please describe.
Sometimes i loose wifi connection for 1 seconds. Then auto tunnel is triggered an start the vpn connection, but it doesn't close it after reconnect

Describe the solution you'd like
a delay for autotunnel would be perfect for this. E.g. you can set a time in seconds after this, condition for autotunnel will be checked and if it's true start the auto tunnel

[zaneschepke]

Hello! What version is this happening on? It should automatically reconnect even if there is a rapid network change.

[popy2k14]

@zaneschepke also for me the issue is back.
We discussed this in a previous issue/version that when I change networks rapidly (same SSID but could shortly fall Back to LTE) there should be:

• Delay of few seconds before switching
• Recheck in an interval

I think you have implemented the first workaround.

Since the update to 3.6.3, it's not working anymore.
I am on my whitelisted Wifi SSID and since the update (few days ago) the tunnel was two times on.

Is the delay present in current versions?
Any chance to implement rechecks in an interval?

Thx

[popy2k14]

Here is the old closed issue: #303

[zaneschepke]

Hey @popy2k14! Yeah, I remember these. Thanks for the additional information and feedback. The thing is both of these solutions are work arounds and don't address the core issue of why things are getting out of sync in the first place. In 3.6.3/3.6.2 had I believed I found and fixed the core issue of these sync problems so I removed these delays/rechecks as I thought they would no longer be necessary.

As I can see you are also reporting that these issues are still present, I'll add back some of these measures to make it more reliable again.

[popy2k14]

@zaneschepke yeah, issue is also back for me.
It seems the workaround is indeed needed in some situations. It worked flawlessly with the workaround of #303 up until 3.6.X.

Nice to hear that you will add back these workarounds.

If you need a tester, I am here.

[Scrounger]

Hello! What version is this happening on? It should automatically reconnect even if there is a rapid network change.

v3.6.3

As I can see you are also reporting that these issues are still present, I'll add back some of these measures to make it more reliable again.

Would be great if you could make this configurable, because I would like to start the vpn connection only after I am no longer in the wifi for a certain time

[popy2k14]

@Scrounger @zaneschepke
I am also on 3.6.3 and the issue happens on this version (i think current play store version).

@zaneschepke
We also discussed a configurable time back than on #303.
I think you decided against an setting to keep the app simple (and the fixed delay value worked also like charm).

I also think a configurable delay in seconds (which defaults and has a minimum of 1 second) would be great.
Please correct me if the default delay was higher in older versions.

The benefit of an configurable delay would be, that the user can increase it if there are switching issues.
As you know, there are so much android manufacturer out there which are also touching the AOSP network switching code (and want to make it better 🤣).

And sure like @Scrounger which want's an higher delay for his use cases.

How do you plan to solve the issue (fixed delay or configurable)?

[zaneschepke]

In the latest nightly build I've added something called a debounce which will delay when there are rapid changes and keep delaying while there are rapid changes then emit the latest value, otherwise for single changea it wont delay. I've added one for network events and one for general auto tunnel state. Would one of you be able to try it out and see if it improves things? I think this is a more robust solution than a standard delay and should hopefully help.

[popy2k14]

@zaneschepke thx for fix. Debouncing is a really nice solution. I have now installed the 3.6.4 nightly with the fix and will report back in a few days.

[popy2k14]

@zaneschepke Sadly, Auto tunneling was stucked and the tunnel was always connected, regardless if my devices was connected to an white listed Wifi or not. Also switching auto tunneling on/off did not help. Just when I disabled the tunnel in the app manually the auto tunneling worked again.

Maybe I had accidentally activated the tunnel manually and overridden auto tunneling. Is this a feature?

I have activated local logging after the issue happened, where is the log file located?

[zaneschepke]

@zaneschepke Sadly, Auto tunneling was stucked and the tunnel was always connected, regardless if my devices was connected to an white listed Wifi or not. Also switching auto tunneling on/off did not help. Just when I disabled the tunnel in the app manually the auto tunneling worked again.

Maybe I had accidentally activated the tunnel manually and overridden auto tunneling. Is this a feature?

I have activated local logging after the issue happened, where is the log file located?

Yikes, that doesn't sound good. :( Thanks again for testing. Did it at least work for a while? Did it become stuck after working for a period of time?

When you enable local logging there will be a logging screen you can navigate to from the support screen by clicking "Read the logs" . On that screen, you can view and copy individual log message or share out the logs.

[popy2k14]

Yeah, i think it worked a day without an hickup.

Sorry totally oversight the logging view function of the app.
So here is the log:

wg_tunnel_logs-1734777104.zip

The issue was around i posted the first post today.
My timezone is Vienna (GMT+1).

I think it's around here in the log:

         1734766912.700  1146  1793 I AutoTunnelService: Detected valid SSID
         1734766934.666  1146  1177 I AutoTunnelService: Detected valid SSID
         1734767000.308  1146  1835 I AutoTunnelService: Detected valid SSID
         1734767022.242  1146  1835 I AutoTunnelService: Detected valid SSID
         1734767028.518  1146  1835 I AutoTunnelService: Detected valid SSID
         1734767056.685  1146  1835 I AutoTunnelService: Detected valid SSID
         1734767059.853  1146  1835 I AutoTunnelService: Detected valid SSID
         1734767063.017  1146  1177 I AutoTunnelService: Detected valid SSID
         1734767072.462  1146  1793 I AutoTunnelService: Detected valid SSID
         1734767084.881  1146  3687 I AutoTunnelService: Detected valid SSID
         1734767100.642  1146  3687 I AutoTunnelService: Detected valid SSID
         1734767116.520  1146  3687 I AutoTunnelService: Detected valid SSID
         1734767150.929  1146  3687 I AutoTunnelService: Detected valid SSID
         1734767154.078  1146  3687 I AutoTunnelService: Detected valid SSID
         1734767162.776  1146  3687 I AutoTunnelService: Detected valid SSID
         1734767165.970  1146  1831 I AutoTunnelService: Detected valid SSID
         1734767172.265  1146  1831 I AutoTunnelService: Detected valid SSID
         1734767192.640  1146  1831 I AutoTunnelService: Detected valid SSID
         1734767192.684  1146  3687 I AutoTunnelService: Detected valid SSID
         1734767192.701  1146  1835 I AutoTunnelService: Detected valid SSID
         1734767417.176  1146  1179 I AmneziaWG/GoBackend: Bringing tunnel <tunnel> UP
         1734767417.452  1146  1179 W AmneziaWG/GoBackend: FD unable to close because it is null
         1734767417.463  1146  1179 D AmneziaWG/GoBackend: Go backend v0.2.11
         1734767417.465  1146  1179 D AmneziaWG/DintisLAN: Attaching to interface tun0
         1734767417.465  1146  1179 D AmneziaWG/DintisLAN: UAPI: Updating private key
         1734767417.465  1146  1208 D AmneziaWG/DintisLAN: Routine: handshake worker 4 - started
         1734767417.465  1146  1208 D AmneziaWG/DintisLAN: Routine: decryption worker 2 - started
         1734767417.465  1146  1208 D AmneziaWG/DintisLAN: Routine: handshake worker 2 - started
         1734767417.465  1146  1208 D AmneziaWG/DintisLAN: Routine: encryption worker 3 - started
         1734767417.465  1146  1307 D AmneziaWG/DintisLAN: Routine: encryption worker 2 - started
         1734767417.465  1146  1208 D AmneziaWG/DintisLAN: Routine: decryption worker 3 - started
         1734767417.465  1146  1179 D AmneziaWG/DintisLAN: UAPI: Removing all peers

I was at home but i tried to disable wifi and enable it again and checked if the issue is gone (tunnel down).
That was not the case, tunnel stayed connected.

After disabling the tunnel in the app (with the switch) it was down and working when i toggled LTE & white listed wifi.

I now leave logging on and if it happens again, post here.

[zaneschepke]

I saw this behavior as well. I just added some changes to the latest nightly that I think will fix these issues if you could give that a try! Thanks again for the testing!

[popy2k14]

Thx a lot for your work and efforts.
Installed it and report back in a few days.

[popy2k14]

Saw that you did a full release, are those fixes included?

[zaneschepke]

Yeah, those fixes are included. Please give the new release a try! I did a full release because there were some other pretty critical bugs with kernel mode that had been resolved so it seemed like a good time to create a new release to fix those bugs.

[popy2k14]

Nice, thx.
Already running the new release.
Will report back here.