Skip to content

Conversation

RobertMe
Copy link

@RobertMe RobertMe commented Aug 3, 2025

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

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.
@RobertMe
Copy link
Author

RobertMe commented Aug 3, 2025

I also tried with a listener for onCapabilitiesChanged, but to me it seems like this only adds more "noise". In that if I disable and then reanable wifi again it shows "retry in 1 minute" after disabling wifi, and after enabling it changes to "3 minutes", "5 minutes", "7 minutes" in quick succession before it finally does connect (which still happens in about a second from enabling wifi).

Copy link
Member

@jmattheis jmattheis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@jmattheis jmattheis merged commit cabd616 into gotify:master Aug 4, 2025
2 checks passed
@RobertMe
Copy link
Author

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.

@jmattheis
Copy link
Member

Yeah, sure, released with v2.9.0. Google Play release follows shortly after it's approved by Google.

@RobertMe
Copy link
Author

RobertMe commented Oct 1, 2025

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?

@jmattheis
Copy link
Member

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.

@RobertMe
Copy link
Author

RobertMe commented Oct 1, 2025

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.

@RobertMe RobertMe deleted the reconnect-changed-properties branch October 6, 2025 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants