Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] - latest update broke the toggle :( #164

Closed
zilexa opened this issue Apr 15, 2024 · 10 comments
Closed

[BUG] - latest update broke the toggle :( #164

zilexa opened this issue Apr 15, 2024 · 10 comments
Assignees
Labels
bug Something isn't working

Comments

@zilexa
Copy link

zilexa commented Apr 15, 2024

Describe the bug
The notification toggle has become useless again, with auto tunnel enabled. You can toggle as much as you want but it will always immediately reconnect, making the toggle useless.
It worked fine for a while.

Smartphone (please complete the following information):

  • Device: [e.g. Pixel 4a] Pixel 4a, ZenFone 9, ZenFone 10
  • Android Version: Android 14
  • App Version [e.g. 3.3.3] 3.4.1

To Reproduce
Steps to reproduce the behavior:

  1. Enable auto tunnel
  2. Leave your trusted wifi.
  3. Notice tunnel connection will be made.
  4. Toggle connection off.
  5. Notice tunnel goes down and immediately up again.

Expected behavior
Notification Toggle is meant to turn the tunnel on/off. Regardless of auto tunnel. In the previous version, this worked: when toggling off, auto tunnel was also paused and automatically resumed when user uses notification toggle to turn back on + automatically resumed when reconnected with trusted WiFi.

@zilexa zilexa added the bug Something isn't working label Apr 15, 2024
@zaneschepke
Copy link
Owner

So in 3.4.1 I change the functionality a bit where toggling via quick tile and shortcuts does not automatically override auto-tunneling (as it could result in undesired behavior in certain situations). To still support this need, I added a second tile and shortcuts that actually controls auto-tunneling pause/resume. This has the added benefit of being able to know the current status of auto-tunneling without opening the app.

On the main screen I could make toggling a tunnel automatically pause auto-tunneling if that is a desired behavior, but I figured it is easy enough to click pause on this screen first. I am open to re-enabling this behavior though as it is more convenient.

As for resuming auto tunneling once you enter a trusted network when it is paused, this has not been added to the app yet but I can see this being useful. Should this be an automatic behavior or should it be a setting that is enabled/disabled?

Thanks again for your continued feedback on the app!

@zilexa
Copy link
Author

zilexa commented Apr 15, 2024

Now I don't understand it anymore.

Indeed, there are 2 notification toggles. But none of them allow me to stop the tunnel.

The usecase here is that I am always using Adguard Home as DNS server (my Wireguard client config files all allow only VPN IP addresses to go through the tunnel, and the VPN server IP is also the DNS server). This way, my Adguard Home is always my DNS server + I can always access my locally running services.

But, some websites don't work well when you block it's ads and trackers. This is an issue when purchasing something on some of those sites. Payment may freeze or fail etc.

In that case, I like to quickly stop the tunnel. With 3.4.1, there is no way of doing that. Because:

  • toggle "auto-tunnel" only stops auto tunneling. Has no effect on the tunnel state.
  • toggle "tunnel control" by design should not be used when auto-tunnel is enabled because the tunnel will simply reconnect.

So the only way for me to pause tunneling is to 1) toggle both toggles each time or 2) open the app.

Adding 2 toggles to the pane seems a bit excessive?
And also, there is another drawback: in the previous version, auto tunneling would automatically resume when you hit the toggle again or when reconnecting to WiFi.
If I now have to toggle both, I am disabling auto tunneling, while my goal was to simply stop the tunnel temporarily..

@zaneschepke
Copy link
Owner

Right, you are correct. The behavior now is you would first click the auto-tunnel tile to pause (assuming auto tunnel active) and then the toggle tunnel tile to stop tunneling. So it would be two clicks instead of one now. I'll give you an example use case of why this is necessary:

State:

  • Auto tunnel paused
  • Tunneled on untrusted wifi

Action: I click the tile to toggle the tunnel off:

  • Auto tunnel is resumed
  • Tunnel is turned off
  • Tunnel is turned back on by auto tunnel because I am on untrusted wifi (not intended)

Now you could say, well, the user should have noticed the auto-tunnel state was paused from the persistent notification so they should have realized what would have happened, but on Android 14 you can dismiss persistent notifications so they may not see or know the state of auto-tunneling. Additionally, they my not realized they are on untrusted wifi. Either way, all they user wanted to do was toggle the tunnel and it didn't happen because of the hidden auto tunnel pause/resume side effect. This scenario looks really buggy and looks like the app is not functioning properly. It is for this reason I decided is it probably best to offer two tiles to control each aspect of the app individually for more consistent outcomes (with the added benefit of seeing auto-tunneling status outside of the app and being more friendly to new users).

I'm sorry for the long winded explanation. I hope that makes more sense now. I realize it is slightly less convenient than the previous method.

I look forward to your thoughts.

@zilexa
Copy link
Author

zilexa commented Apr 16, 2024

But I still don't understand why you changed this? It worked fine before. I can't add 2 toggles. I don't have the space for it and I don't use multipage toggles. It also makes no sense to ask users to use 2 toggles just to pause their tunnel 🤷🏽‍♂️
I use this also for family members so they don't get overloaded with ads. But this change cannot be explained to a non technical expert who hasn't read up all of this.

so they may not see or know the state of auto-tunneling. Additionally, they my not realized they are on untrusted wifi. Either way, all they user wanted to do was toggle the tunnel and it didn't happen because of the hidden auto tunnel pause/resume side effect. This scenario looks really buggy and looks like the app is not functioning properly. It is for this reason I decided is it probably best to offer two tiles

No, it worked totally fine before without appearing buggy at all. Auto Tunnel worked fine. The toggle would not only pause it but stop the tunnel as well. And it autoresumed when connected to your trusted wifi or when toggling again.

It seems you forgot how well this worked? Because you are describing a situation of much older versions.

Please consider restoring the functionality as it was.
Nobody is this focused on their tunnel to work with 2 toggles. The app was fantastic as "set once and forget". Now it needs constant thought about 2 toggles and what the 4 different states might mean..

Sorry to say but this seems to be a textbook example of overdesign..

@zilexa
Copy link
Author

zilexa commented Apr 16, 2024

An even simpler way would be to limit auto tunnel to perform an action when the network connection changes. Which would make more sense actually, because those are the moments the tunnel is set up anyway.
Auto tunnel = toggle on network connection state (based on the selected user settings such as trusted wifi)
Notification toggle: turn tunnel on/off, without messing with auto tunnel.

Auto tunnel would then simply kick in when a network change takes place, for example when going from untrusted WiFi to mobile, or from mobile to mobile, or from mobile to trusted WiFi.

This is identical as to how people use the official app (with its toggle) in combination with Automate or Tasker (acting on network connection state changes only).

@zaneschepke
Copy link
Owner

An even simpler way would be to limit auto tunnel to perform an action when the network connection changes. Which would make more sense actually, because those are the moments the tunnel is set up anyway. Auto tunnel = toggle on network connection state (based on the selected user settings such as trusted wifi) Notification toggle: turn tunnel on/off, without messing with auto tunnel.

Auto tunnel would then simply kick in when a network change takes place, for example when going from untrusted WiFi to mobile, or from mobile to mobile, or from mobile to trusted WiFi.

This is identical as to how people use the official app (with its toggle) in combination with Automate or Tasker (acting on network connection state changes only).

This sounds good. I'll have to see how it works in practice, but overall I like the idea.

@R7010A
Copy link
Contributor

R7010A commented Apr 21, 2024

I agree with @zilexa.
I have the same problems with v3.4.1 and the idea from zilexa is great.
I tried to solve the problem with tasker, but it failed. So it would be amazing to build in this feature.
Please make WG tunnel as simple as possible for the users.
Anyway, thanks for this amazing tool.

@weedy
Copy link

weedy commented Apr 22, 2024

I would argue if we are going down the road of 2 buttons because we don't know the state of auto toggle at that point it the old button if auto toggle is enabled disable the tunnel for X minutes.

I would agree the desired function is the tunnel is causing an issue and I need to temp disable it. But if I've configured auto toggle I specifically want and expect to be tunneled "at all times".

@zaneschepke
Copy link
Owner

I implemented what @zilexa and @R7010A recommended and changed auto-tunneling to only change vpn state on network change so it will no longer continue to keep turning on the connection when you manually toggle off (until the next network state change). This change should be live in https://github.com/zaneschepke/wgtunnel/releases/tag/3.4.3.

Let me know if there are any issues/feedback on this behavior, but I'll mark this as closed for now.

@zilexa
Copy link
Author

zilexa commented May 13, 2024

This is fantastic, such a short turnaround time. Thanks, will test!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants