Fix outbound link-local connections on mobile #1300
Conversation
neilalexander
left a comment
neilalexander
left a comment
There was a problem hiding this comment.
Is the l.handleInterfaceError case even needed? The log that you show in the PR description shows that it finds the addresses successfully?
Therefore is it only the // Mobile platform workaround section that is required here?
DrewCyber
force-pushed
the
yggstack-android-fixes
branch
from
c97f78d to
4949b90
Compare
|
Agree. I reverted Looks like the main issue on Android - net.InterfaceByName() calls can fail due to permission restrictions (like SELinux on Android). This caused connection failures even when the network interface information was sufficient for routing. And we got Not sure if this applies to other platforms besides android. Please let me know if any improvements or squash needed. |
On Android, InterfaceByName can fail due to SELinux restrictions, but for link-local addresses with zone identifiers, the zone is sufficient for routing and we can proceed without source binding. This fixes the 'interface wlan0 not found' error during multicast peer discovery.
|
Just tested on Android. Both link-local connections (inbound and outbound) works well. |
neilalexander
left a comment
neilalexander
left a comment
There was a problem hiding this comment.
I think this is OK, thanks!
2 participants
On mobile platforms if multicast discovery enabled, we can get only inbound connections. Outbound connections doesn't work because of interface lookup errors.
For link-local addresses with zone set, we can proceed without binding. The zone identifier tells the kernel which interface to use
2025/12/22 16:53:17 Discovered addresses for interface wlan0: [192.168.1.125/24 2a06:63c5:9304:c000:5038:f8e3:6d4a:39d6/64 2a06:63c5:9304:c000:8483:3eff:fe63:4b4b/64 fe80::8483:3eff:fe63:4b4b/64]2025/12/22 16:53:17 Dialling tls://[fe80::d905:52e3:b183:5d01%25wlan0]:41315 reported error: interface "wlan0" not found