It’s a pain in the ass if the address are dynamic. And we can detect that two nodes are in the same private net. I think there are many corner cases that can be solved by something like this, and this kind of networks where broadcast / multicast discovery won’t work are not uncommon. In corporate environments are quite common actually.
Over on the syncthing-android forum, it was discovered that a small bug in the latest Android app is blocking connections from the device on a LAN to remote nodes outside the LAN.
The fix is simple. In the Android app - go into the Web GUI and then select Edit > Settings. In the Global Discovery Server field, edit the port number from 22025 to 22026.
In a corporate env, you could probably use DNS (names are fine as node addresses) or use a local discovery server.
But, I’m not really strongly opposed to announcing local addresses, as a default-off option. There are some technical annoyances to solve though. The set of local addresses might be fairly large and change quite often:
jb@jborg-mbp:~ $ ifconfig | egrep 'inet|inet6' | grep -v 127.0.0 | grep -v ' ::1' | grep -v fe80::
inet6 2001:470:deeb:32:22c9:d0ff:fe43:c95 prefixlen 64 autoconf
inet6 2001:470:deeb:32:8090:e9be:5a7a:3650 prefixlen 64 autoconf temporary
inet 172.16.32.207 netmask 0xffffff00 broadcast 172.16.32.255
inet 192.168.6.106 --> 192.168.6.105 netmask 0xffffffff
inet 192.168.29.1 netmask 0xffffff00 broadcast 192.168.29.255
inet 192.168.126.1 netmask 0xffffff00 broadcast 192.168.126.255
so we’ll probably need to always send the full set and the client should connect to them in parallel to save some time. Probably we should avoid trying addresses that we know are our own (every computer with vmware fusion is going to have the 192.168.126.1 address, etc).
Right, yeah. The discovery format changed in v0.9 (because there was a bug in the XDR encoding in v0.8), so I used a new port for the new format to be able to have both running at the same time. Syncthing upgrades this when it converts old configs, and uses the new port by default in new installations, but perhaps not in the Android app yet.
If you are open to this I can try to work on the feature.
Certainly, you’re welcome to.
Looking at the discosrv code I think it already supports this, which is good. It saves all the addresses present in the announce packet, while replacing any zero-sized addresses with the source address the packet came from. So you’ll want to send a discovery packet with one blank address + correct port (as now), plus including the rest of the addresses you want to include with the relevant listening port.