[PM-40402] SocketTimeoutException trying to connect to directly attached IPv6 addresses

[jfly]

Steps To Reproduce

1. Host a bitwarden server on your local network, accessible only over IPv6 (for example, some IPv6 ULA such as fdd4:aa51:eed9:426:9f99:938b:ebf9:7433, accessible via bitwarden.example.com, which you'll see the in stacktrace below.).
2. With your android phone connected to the same local network: open bitwarden, on the login screen, select "Self-hosted", tap "Self-hosted", and enter the url of your server (in this example: https://bitwarden.example.com).
3. Try to log in. You'll experience a delay after pressing "Continue" on the login screen, but you will eventually make it to the master password prompt screen.
4. On the master password prompt screen: enter your master password and click "Log in with master password". After 10 seconds of "Logging in...", you'll get a popup that says "An error has occurred. We were unable to process your request. Please try again or contact us." If you click "Share error details", you'll see a stacktrace of a SocketTimeoutException (full trace below).

Expected Result

I expect to be able to log into my bitwarden server.

Actual Result

Here's the stack trace:

Stacktrace:
java.net.SocketTimeoutException: failed to connect to bitwarden.example.com/fdd4:aa51:eed9:426:9f99:938b:ebf9:7433 (port 443) from /fdd4:aa51:eed9:426:9f99:93b5:4d8:4a2e (port 38658) after 10000ms
	libcore.io.IoBridge.connectErrno(IoBridge.java:235)
	libcore.io.IoBridge.connect(IoBridge.java:179)
	java.net.PlainSocketImpl.socketConnect(PlainSocketImpl.java:142)
	java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:390)
	java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:230)
	java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:212)
	java.net.SocksSocketImpl.connect(SocksSocketImpl.java:436)
	java.net.Socket.connect(Socket.java:646)
	ev1.i(r8-map-id-01e002bd0632bb5cc7de20747ff74afc7c2ccce2c9b98107678ea7daf8b79b97:77)
	ev1.d(r8-map-id-01e002bd0632bb5cc7de20747ff74afc7c2ccce2c9b98107678ea7daf8b79b97:38)
	r63.a(r8-map-id-01e002bd0632bb5cc7de20747ff74afc7c2ccce2c9b98107678ea7daf8b79b97:3)
	ia.a(r8-map-id-01e002bd0632bb5cc7de20747ff74afc7c2ccce2c9b98107678ea7daf8b79b97:67)
	ia.run(r8-map-id-01e002bd0632bb5cc7de20747ff74afc7c2ccce2c9b98107678ea7daf8b79b97:82)
	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1100)
	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	java.lang.Thread.run(Thread.java:1572)

Version: 2026.6.1 (21713)
Device: 📱 google Pixel 6 🤖 17@37 📦 prod -fdroid
CI: 🧱 commit: bitwarden/android/release/2026.6-rc57@e5ee43f68773f9fe20bec3dd664781d65b804967
💻 build source: bitwarden/android/actions/runs/28253991408/attempts/1

Screenshots or Videos

No response

Additional Context

The last version of the app where this worked was 2026.5.0. I tested 2026.6.1, 2026.6.0, and 2026.5.1 and confirmed they do not work.

I bisected and found that this was introduced by #6916, which upgraded the android sdk from 36 to 37. One consequence of sdk version 37 is that local network permission is now disabled by default. The bitwarden android app only requests local network access if the address we're connecting to is a "site local address", as returned by InetAddress.isSiteLocalAddress. Here are the implementations for ipv4 and ipv6:

• ipv4: https://android.googlesource.com/platform/libcore/+/android-17.0.0_r1/ojluni/src/main/java/java/net/Inet4Address.java#239
  • RFC 1918 calls these "private" addresses
• ipv6: https://android.googlesource.com/platform/libcore/+/android-17.0.0_r1/ojluni/src/main/java/java/net/Inet6Address.java#365
  • This implements ipv6's long-deprecated "site local addresses". The modern replacement are unique local addresses (ULAs). Wikipedia has a decent history: https://en.wikipedia.org/wiki/Unique_local_address#History).

However, I don't think the correct fix here is to just add "is ula?" to the check. I believe the intent of the code is to check "would android block connections to this ip address?", which android conveniently documents on their Local Network Definition page. Fun fact: this reveals that our ipv4 check is likely wrong as well (android blocks link local and CGNAT addresses, which are not detected by Inet4Address.isSiteLocalAddress). The IPv6 check is even harder to implement, as it's not just a comparison against static subnets, it depends on your routing table.

AFAICT, there's no easy way to implement this check (I've asked android for advice on this in https://issuetracker.google.com/issues/534973523). I think one correct way to do it is to just try and check for the error reason afterwards with android_getnetworkblockedreason, but I guess that requires trying and waiting for a timeout, and it requires using the NDK.

Perhaps the least odious approach would be to prompt the user for local network permission if they select "Self-hosted"? Or catching SocketTimeoutException and warning the user that they might need to grant the "Nearby devices" permission?

Build Version

2026.6.1 (21713)

What server are you connecting to?

Self-host

Self-host Server Version

I promise this is not relevant

Environment Details

• Device: Google Pixel 6
• Android version: 17

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[bitwarden-bot]

Thank you for your report! We've added this to our internal board for review.
ID: PM-40402

[jfly]

For the record, I filed https://issuetracker.google.com/issues/534973523 with Android seeking advice on what the right way to do this is (I suspect the answer is that currently, there is no good way).

[daniellbw]

Hi there,

This issue has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!

[Zyrando]

Confirming this bug with an extra data point: it also affects global-scope IPv6 addresses, not just ULAs.

• App: 2026.6.1 (21713), same build as OP
• Device: Pixel 8 Pro, Android 17 (17@37)

My server has a global IPv6 (2a00:6020:..., EUI-64) and my phone is in the same /64 (a privacy-extension address in the same prefix), so the target is directly attached at the link but global-scope rather than a ULA. Same result: SocketTimeoutException on Socket.connect after 10000ms, and nothing reaches the reverse proxy, while the mobile browser on the same phone connects fine.

This matches the analysis: isSiteLocalAddress returns false for a global address, so the app never requests local network permission and Android silently blocks the connection. It reinforces that a static subnet check isn't sufficient — a global address can still be link-local-reachable and blocked, depending on the routing table.

Manually granting "Nearby devices" (Settings → Apps → Bitwarden → Permissions → Nearby devices → Allow) fixes it. The permission prompt never appeared on its own for this address.

[jfly]

@Zyrando, yes, the issue is not specific to ULAs, that was just my specific use scenario. And yes, the workaround you describe (manually granting the "nearby devices" permission) works, the issue is that Bitwarden isn't prompting the user to do it.