celzero
WireGuard sometimes stuck in "Waiting" forever
But that is not not the only problem I noticed (and this is what I never noticed before):
even if ReThink has learned of the changed IP, the Wireguard connection still does not react. Instead, it stays stuck in "waiting" - "failing" - "waiting" - "failing". This state did not change for the last 45min. Using the button you suggested did not help at all.
In this state, I can
toggle the "total blockage" button within the Wireguard connection off/on which for some reason helps somtimes, but in other cases only resets the Upload/Download counter in the Wireguard Proxy view
toggle the Wireguard connection itself off/on which then usually resolves the issue but lets all waiting connections briefly get out of the VPN tunnel.
Originally posted by @Braintoe in #1808
WireGuard may get stuck in "Waiting" when its configuration fails to "add" itself (either upon user toggling via the UI or user changes to configuration via the UI or a programmatic background "refresh") to network engine's "Proxies". We've since identified a fix for this which should land in v055o, the upcoming version.
And when is. 55o? It's been 8 months and I'm still dealing with bugs "fixed in the new version ready for release next week"
I hear you.
v055x series have been very buggy. That's mostly down to the new features, like WireGuard.
You'd have noticed we released v055a..n in very quick cycles but the bugs simply won't go away.
And so, we had no choice but to prioritise stability and as we were doing that, we encountered more bugs in our own testing. This means things kept changing. And just when we thought we were ready, something new and terrible would crop up.
Since a long time had passed already, and we were more than half-way through #946, we decided to complete it.
In Dec 2024 both the developers went on a month-long leave and that derailed the progress a bit.
Since #946 is multiple paid features, we are being extra cautious in making sure very obvious or very severe bugs don't sneak through (refunds are expensive as taxes are not refunded; fraud is expensive). This has been a slow processes, unfortunately. But one that we think is near completion. There's just 1 developer on the app, after all.
All of this isn't meant to be an excuse but just a window into what's really going on.
It's been 8 months and I'm still dealing with bugs "fixed in the new version ready for release next week"
🤨
To be honest, I would have simply answered "when it's ready".
Let me put it like this: @ignoramous and his team
- have invested and continue to invest a lot of time and effort in creating and maintaining ReThinkDNS
- created a really great alternative to the "two big old" Android privacy tools, namely AfWall (which requires Root) and Netguard (which works very reliably but where the developer sadly has lost any interest in listening to his users and improving the program apart from some bugfixing - I do not blame him and I understand at least part of his reasons, but I also believe a significant part of his frustration is caused by himself)
- make the result of their efforts Open Source, only hoping on people to be genereous and reward them a bit by donating something (and do not even add a nag screen into the app)
Thus, IMO, nobody of us users has the right to complain about any missed timelines.
You want something? Ask - and be patient.
You want something quick? Fork, create and contribute actively, if you are a programmer for... Java and Kotlin in this case.
For the rest of us, including myself: donate, even if it is just a dollar each month - and convince others you know use this program to donate as well. The more people donate, the more time and effort can be invested. I am quite sure that a dream will come true for the team if ReThink pays off enough in recurring donations to let them improve this app full-time and be able to live from it.
I know what you trying to get across. But considering the rapid pace of releases at the beginning, not even getting hot fixes for so long is a pain.
N introduced some kind of thread lockup that just crashes system_server at random at traffic levels over 1MiB/s.
Doing more then loading web pages or refreshing gmail soft reboots my phone for the past 8 months.
I have been patient, I'm continuing to be patient.
Well, sure - in the beginning you want to get your "baby" flying, but after a while daily life kicks in, especially if you find your efforts are not honoured that much to change the way you earn your living. Here on Github, you can see that Rethink earns the guys just 35 Dollars a month from just nine persons - miserably little for this great piece of software and obviously not enough to make a living from it.
I can however tall you that on my phone I do not experience that issue at all - apart from the reconnection issues after each reboot or DSL router restart mentioned here, 100% of my phone traffic runs over ReThink and into my Wireguard VPN since I switched over from Netguard over a year ago, and it runs flawlessly on my Samsung. Apart from some issues with updating the blocklists wich have been solved with 0.55n or the version before that, I had not a single crash or lockup of ReThink during that time.
I know this does not solve your problem, but this means you experience something specific that does not affect all users - which automatically decreases the severity of the issue from the programmer's point of view... I don't know if it makes sense and I do not know any details on your issue, but I can offer you we compare settings, maybe that helps.
But for now I need to go to bed - it's late here in Germany :-)
I appreciate both: The demanding users and the supportive ones. It is a nice balance (:
Either ways, v055o then v055p[^0] has several improvements wrt WireGuard reconnectivity. Please do test and let me know if the bugs you folks saw have disappeared: https://github.com/celzero/rethink-app/releases/tag/v0.5.5p
[^0]: Note: v055p is a pre-release.
While I focus on the "reconnect after IP change of Wireguard server" issue, I can say so far that despite quite some playing around with my Wireguard connection by toggling between my IP4, IP6 and dual stack connection, I did not get a wait loop at all. The only hiccup I had was when I started the IP6/dual stack connection with ReThink still being set to IPv4-only - which lead to an unresponsive Wireguard tunnel since Rethink obviously wanted to create an IP6 tunnel but was prevented to do so by its own setting. (Some error message might be helpful there ;-) )
Since I have changed that: looks good or at least much better so far, at least as far as I can tell after the first hour or so.
Since I have changed that: looks good or at least much better so far, at least as far as I can tell after the first hour or so.
You mean Peer endpoints behind DynDNS works as expected?
I started the IP6/dual stack connection with ReThink still being set to IPv4-only - which lead to an unresponsive Wireguard tunnel since Rethink obviously wanted to create an IP6 tunnel but was prevented to do so by its own setting. (Some error message might be helpful there
Is WireGuard IPv6-only? If so, what you say is right. Rethink would prefer IPv4 and fail to use IPv6-only WireGuards. I am surprised we do not surface this mismatch as error message to the end-user ... we should: https://github.com/celzero/rethink-app/issues/2053
Since I have changed that: looks good or at least much better so far, at least as far as I can tell after the first hour or so.
You mean Peer endpoints behind DynDNS works as expected?
Yes, they do, but I still need to reset the network connection --> issue #1808 :-)
I started the IP6/dual stack connection with ReThink still being set to IPv4-only - which lead to an unresponsive Wireguard tunnel since Rethink obviously wanted to create an IP6 tunnel but was prevented to do so by its own setting. (Some error message might be helpful there
Is WireGuard IPv6-only? If so, what you say is right. Rethink would prefer IPv4 and fail to use IPv6-only WireGuards. I am surprised we do not surface this mismatch as error message to the end-user ... we should: #2053
Wireguard is whatever you tell it to be - IPv4 only, dual stack or IPv6 only. You define that simply by defining either IPv4 or IPv6 DNS and client IPv6 addresses or both in the tunnel settings on the server and client. I have the following: setup: the Wireguard server on my Raspi is dual-stack capable. If I define IPv4 addresses in the "address" and the "DNS" field of the client (ie. RethinkDNS), I get an IPv4 connection, if I define IPv6 addresses, I get IPv6 and if I define both, I get a dual stack IPv4+6 connection without needing to change anything on the server.
With this and Rethink being set to "IP version = IPv4" in the network settings, I get the following result
- Wireguard IPv4-only: works
- Wireguard IPv6-only: hangs or seems to connect but does not work because Rethink correctly does not use IPv6 due to its setting.
- Wireguard IPv4+6 dual stack: connections seem to hang or connect at random, as app-connections lateron do.
If I set Rethink to "IP version = Auto" in the network settings, I get the following result:
- Wireguard IPv4-only: works
- Wireguard IPv6-only: works, from what I tested as long as the connection endpoint (e.g. a website) works on IPv6
- Wireguard IPv4+6 dual stack: works (albeit a bit laggy) and seems to prefer IPv6 over IPv4 which is the opposite of what you wrote.
Wireguard IPv4+6 dual stack: connections seem to hang or connect at random, as app-connections later on do.
Strange. If you've switched, does this happen on v055u, for you?
In v055u, Rethink also re-configures from scratch a WireGuard tunnel that's "Waiting" on network change and/or on tapping the "Refresh" icon at the top right-hand side of the UI Configure -> Proxy.
Wireguard IPv4+6 dual stack: works (albeit a bit laggy) and seems to prefer IPv6 over IPv4 which is the opposite of what you wrote.
That's okay, too! In fact, this is expected iff dual-stack. The situation I tried to highlight was: If the underlying network (wifi/mobile/etc) have IPv4 but the WireGuards setup (either in Simple or Advanced modes) are IPv6-only (no IPv6 interface address), then Rethink will prefer IPv4 (as part of the tunnel) over IPv6, which may result in WireGuards losing connectivity if Configure -> Network -> Choose IP version is set to Auto.
Btw, v055u has a setting to force dual-stack tunnel wide; select IPv4 & IPv6 from Configure -> Network -> Choose IP version (note that, if in Advanced mode, this might result in IPv4-only routing WireGuards to "leak" IPv6 packets on to other Always-on WireGuards if setup, or to the underlying network, like Wifi / Mobile, itself).