Try reconnecting after link properties changed#418
Conversation
In some circumstances (like the server only being reachable over IPv6) reconnecting when the network becomes available doesn't work. This due to the network only being "partially" available (in the example: IPv4 working, but IPv6 not yet). By also listening for changes of the link properties a new connection attempt is made when for example the IP addresses of the link, or the networking routes change. Meaning that the example issue is fixed, as a new attempt is made after the IPv6 address is set on the link / the routes for IPv6 networking are available.
|
I also tried with a listener for |
|
If I may be so free to ask. A release containing this fix would be nice :) Saves me from having to run a custom build and "monitoring" if I can switch back to the normal (store) release. |
|
Yeah, sure, released with v2.9.0. Google Play release follows shortly after it's approved by Google. |
|
Awesome. Just checking though. I can see the new version in the Play Store, but not in F-Droid. I'm rather unfamiliar with the processes, but I'm seeing something of some automatic build on their end? But it might also be "validation" that the build is reproducible? (also seeing something like that) So not sure whether you should upload the APK / ... manually (and possibly forgot), or that some automatic process failed? |
|
This is fully automated by F-Droid. The new version was already updated in the metadata but wasn't built yet. The currently running build is still processing the updates from 2 days ago. Gotify will be built in the next batch. It'll just take some time. Looking at the older releases it takes 2-5 days for the release to be available in F-Droid. |
|
Thanks for the explanation. I did see/find the "metadata update", but didn't know about the automatic building and that it probably takes a couple of days before it is processed. |
In some circumstances (like the server only being reachable over IPv6) reconnecting when the network becomes available doesn't work. This due to the network only being "partially" available (in the example: IPv4 working, but IPv6 not yet). By also listening for changes of the link properties a new connection attempt is made when for example the IP addresses of the link, or the networking routes change. Meaning that the example issue is fixed, as a new attempt is made after the IPv6 address is set on the link / the routes for IPv6 networking are available.
As discussed