I fear the topic has seen quite its share of discussions already but hear me out.
The problem nowadays is that the discovery of interface IPs throws an error on Android. As far as I’m aware broadcast/multicast would still work, we’re just erroring out before we get to that point?
Would it be possible to catch that error and still send the broad- or multicast? The idea here would be that the other client can obtain the address from the packet it just received.
We’re doing something similar for global discovery if i’m not mistaken. The approach would work even more reliably for local networks, as we’re not dealing with NAT.
The code is in here if you want to experiment:
We list addresses on IPv4 in order to send directed broadcasts to each subnet, but there’s also a fallback to all-ones so that could work.
For IPv6 we don’t care about addresses, but we need to bind to each interface (hence list them) as the multicasts are link local.
Not a go dev but it looks like we break out of the loop on the first interface discovery error?
And also for the IPs
Wouldn’t it be enough to capture and log the error thrown by
intf.Addrs() and carry on with an empty array of addresses?
The fallback provided by
len(dsts) == 0 should be enough to send a broadcast.
The receiving party would need to generate an address based on the origin of the broadcast.
Maybe, if there’s a case where asking for interface addresses returns an error but it’s still possible to use the interface. Maybe android is that case, I don’t know.
Exactly. That functionality is broken on Android.
The best case scenario would be to have the IP discovery a bit more resiliant and try to send a broadcast in any case. That would avoid Android specific hacks and still fix local discovery.
Someone should try it. That call failing doesn’t necessarily mean everything else will work if we just ignore the failure…