[Bug]: Quick Tile shows 'connected' even if the connection has failed #93

m4callik commented 2025年08月24日 22:56:15 +02:00

Please confirm that:

• I have searched the issues and didn't find my bug or an answer to my question
• My bug is about JetBird and not something upstream

What is your JetBird version?

1.4.3

What make/model is your device?

Pixel 7a

What OS and version are you running?

Graphene OS Android 16 (20250814)

What happened?

I toggle jetbird almost exclusively via the quick tiles.

I've noticed a few times where I've turned jetbird 'on' via the quick tile, only to realize an hour later that the connection failed when I cannot access external networks.

For me, I believe I have pinpointed the cause for the failed connection (GrapheneOS upgrade -> reboot -> use netbird before post-upgrade apps optimization + apps restart has taken place) and it resolves itself when I optimize apps and/or reboot, which makes sense.

The ticket is to look into whether the app can avoid saying a connection succeeded in these instances, or notify the user of the failure if the quick tile for VPN is an upstream quirk. Being that GrapheneOS updates a few times a month, the issue is more noticeable there than other phones/distros which tend to update quarterly/annually (if at all) FYI.

### Please confirm that: - [x] I have searched the [issues](https://codeberg.org/bg443/JetBird/issues) and didn't find my bug or an answer to my question - [x] My bug is about JetBird and not something upstream ### What is your JetBird version? 1.4.3 ### What make/model is your device? Pixel 7a ### What OS and version are you running? Graphene OS Android 16 (20250814) ### What happened? I toggle jetbird almost exclusively via the quick tiles. I've noticed a few times where I've turned jetbird 'on' via the quick tile, only to realize an hour later that the connection failed when I cannot access external networks. For me, I believe I have pinpointed the cause for the failed connection (GrapheneOS upgrade -> reboot -> use netbird before `post-upgrade apps optimization + apps restart` has taken place) and it resolves itself when I optimize apps and/or reboot, which makes sense. The ticket is to look into whether the app can avoid saying a connection succeeded in these instances, or notify the user of the failure if the quick tile for VPN is an upstream quirk. Being that GrapheneOS updates a few times a month, the issue is more noticeable there than other phones/distros which tend to update quarterly/annually (if at all) FYI.

bg443 commented 2025年09月06日 10:45:51 +02:00

Hi,

Just wanted to let you know I am still trying to reproduce this.

Does this also happen on a regular reboot for you as well? Do you need to reauthenticate after you've realised you can't connect to external networks?

Thanks!

Hi, Just wanted to let you know I am still trying to reproduce this. Does this also happen on a regular reboot for you as well? Do you need to reauthenticate after you've realised you can't connect to external networks? Thanks!

m4callik commented 2025年09月28日 03:30:58 +02:00

It hasn't happened once since I've loaded the ticket. (I have slowed my updating cadence as GrapheneOS works through upstream Android shenanigans too tho).

Also realize I was vague, and when I said connect to external networks, I was referring to my LAN which is typically accessible through LAN.

But yeah, just tried a few scenarios

1. Tried during validating system update - successful
2. Tried during system-wide app update - successful
3. Tried after system-wide update but before restarting the optimized apps - successful

Maybe it was fixed upstream or something? Thanks for looking into it!

It hasn't happened once since I've loaded the ticket. (I have slowed my updating cadence as GrapheneOS works through upstream Android shenanigans too tho). Also realize I was vague, and when I said connect to external networks, I was referring to my LAN which is typically accessible through LAN. But yeah, just tried a few scenarios 1. Tried during `validating system update` - successful 2. Tried during system-wide app update - successful 3. Tried after system-wide update but before restarting the optimized apps - successful Maybe it was fixed upstream or something? Thanks for looking into it!

m4callik commented 2026年02月06日 17:24:47 +01:00

I think I'm able to replicate the issue consistently now. My new understanding is that it has to do w/ the handoff/handover between mobile data + wifi data + vpn.

• Works - Disconnect wifi -> connect to mobile data -> connect to vpn
• Works - Connect to vpn -> disconnect from wifi -> fallback to mobile data
• Fails - Walk out of range of wifi -> Connect to VPN - > Turn Off Wifi -> No VPN connection until data VPN is toggled off/on again

The VPN is able to 'see' the peers but either

• all network traffic fails
• local sites work, but DNS resolution fails everywhere else (ie I can retrieve search results w/ my self-hosted search engine @ g.lan but when I click any of the outgoing links, they all error out)

Not sure if this warrants reopening the tix or if this is more of an Android/upstream quirk.

I think I'm able to replicate the issue consistently now. My new understanding is that it has to do w/ the handoff/handover between mobile data + wifi data + vpn. - `Works` - Disconnect wifi -> connect to mobile data -> connect to vpn - `Works` - Connect to vpn -> disconnect from wifi -> fallback to mobile data - `Fails` - Walk out of range of wifi -> Connect to VPN - > Turn Off Wifi -> No VPN connection until data VPN is toggled off/on again The VPN is able to 'see' the peers but either - all network traffic fails - local sites work, but DNS resolution fails everywhere else (ie I can retrieve search results w/ my self-hosted search engine @ `g.lan` but when I click any of the outgoing links, they all error out) Not sure if this warrants reopening the tix or if this is more of an Android/upstream quirk.

m4callik commented 2026年05月08日 18:56:20 +02:00

99.9% sure this is the case now as I can avoid it consistently and resolve it on the rare times it does occur

The brief explanation from my experience is that there needs to be an active connection when Jetbird is enabled, and you need to wait 2-3 seconds before switching to a different connection or else Jetbird will silently fail. (ie: If connected to wifi, turn on jetbird, then wait 3-4 seconds, then you can turn off wifi so that the phone falls back to mobile)

Failure to wait 3-4 seconds between the transition results in a VPN connection w/ limited data transiting inside/outside of the tunnel.

99.9% sure this is the case now as I can avoid it consistently and resolve it on the rare times it does occur The brief explanation from my experience is that there needs to be an active connection when Jetbird is enabled, and you need to wait 2-3 seconds before switching to a different connection or else Jetbird will silently fail. (ie: If connected to `wifi`, turn on jetbird, then wait 3-4 seconds, then you can turn off `wifi` so that the phone falls back to `mobile`) Failure to wait 3-4 seconds between the transition results in a VPN connection w/ limited data transiting inside/outside of the tunnel.

bg443 commented 2026年05月10日 12:50:02 +02:00

I'll see if there's anything that can be done on the JetBird side.

There have been reports of connection issues when changing network: https://github.com/netbirdio/android-client/issues/146

I'm following any changes that are being made upstream and porting them to JetBird where possible.

I'll see if there's anything that can be done on the JetBird side. There have been reports of connection issues when changing network: https://github.com/netbirdio/android-client/issues/146 I'm following any changes that are being made upstream and porting them to JetBird where possible.