I use two instances of Syncthing on one machine, each instance for a user. Whatever I do, one of these instances never manages to find other local nodes via local discovery and only connects to them via global discovery (internet IP). Here is what I tried. In ~./config/syncthing/config.xml I changed:
<listenAddress> from 0.0.0.0:22000 to 0.0.0.0:22000, so both instances have a unique <listenAdress>
<localAnnouncePort> from 21025 to 21027
<localAnnounceMCAddr> from [ff32::5222]:21026 to [ff32::5222]:21028
I tried all possible combinations and nothing succeeded. Of course, <localAnnounceEnabled> is set to true. What am I doing wrong?
The localAnnouncePort and localAnnounceMCAddr must be the same on all devices who are going to find each other on a LAN. The first is used for IPv4 broadcasts, the second for IPv6 multicasts.
For IPv4 broadcasts, only one program can open the port at a time, so only the first syncthing you start will be able to use discovery over IPv4. The IPv6 multicasts don’t suffer from that limitation, but require that you have IPv6 enabled on your computers (which ought to be the default pretty much everywhere though).
Two syncthings on the same machine won’t find each other though, multicast or not, but in that case you can simple set the addresses statically.
Thank you for explaining. It makes sense, now. I checked again and realized, local discovery via IPv6 works with other clients. You are right, it doesn’t work with two instances on the same machine.
but in that case you can simple set the addresses statically.
I’m not sure, if I understand that. Giving the machine with the two instances a static IP? How is that going to help?
The config file of both instances already has fixed ports and addresses, doesn’t it?
I changed listenAddress from 0.0.0.0:22000 to 127.0.0.1:22000 for the first instance and for the second instance from 0.0.0.0:22001 to 127.0.0.1:22001 on the same machine. With that setting active, neither local nor global discovery works. Both instances won’t see the other. Using the 0.0.0.1:portnumber addresses, global discovery worked, at least.
I kept digging a bit into the local discovery. I will call the machine with the two instances running the server and the machine I’m working on the client. I realized, that the IPv6 address my Syncthing client connects to is different from the IPv6 I get from “ping server”. The first 4 phrases (xxxx:xxxx:xxxx:xxx) are the same but for the next 4 phrases, they differ (x00:000x:00x0:00x0 vs 0000:x0xx:xx00:xxxx). So I disabled “global discovery” for the Syncthing client and the server to check, if the machines connect via internet or via LAN. With this setting applied, Syncthing client will find only the first instance on the server. The second one is practically unavailable in the local network and connection to it can only be established via internet.
I uploaded a log file and the configuration files.
Here is the output of STTRACE=discover ./syncthing:
http://pastebin.com/HSfGH7v7
It is the second instance and has been started after the first instance on the Syncthing server. It’s configuration file is here:
http://pastebin.com/EVWeLGGa
So you should add additional localhost addresses for the devices.
Instance one should have address for instance two:
dynamic 127.0.0.1:22001
And instance two should have addresses for instance one:
dynamic 127.0.0.1:22000
Thank you, @AudriusButkevicius. I misunderstood the address field @calmh was walking about. I was still fiddling on listeningAddress, overlooking the address fields for every device. The address field set to dynamic, 127.0.0.1:22001 for instance two and dynamic, 127.0.0.1:22000 for instance one, both can connect without global discovery. Note, I had to add a comma when using the WebGUI before it worked.
However, the server instance started last still cannot be discovered from my Syncthing clients via IPv6 when global discovery is disabled. What is the problem here?
I run all three instances, two on the server and one on the client, with STTRACE=discovery,beacon. The log files have no obvious error messages. The first instance on the server is able to connect to the client (IPv4). The log file of the second instance on the server never mentions the Syncthing client (except for the beginning, where it lists all known nodes). Also the log file of the Syncthing client never mentions the second instances node ID (again, except for the beginning).
All three instances have the same localAnnounceMCAddr and do not use global discovery. When global discovery is set to true, the nodes find each others IPv6 (if IPv4 port is already used ).
Maybe this detail helps? Both instances on the server have the following line repeatedly in their log files:
[XXXX] 2015/03/12 17:58:41.164905 multicast.go:75: DEBUG: sent 56 bytes to [ff32::5222%eth0]:21026
But the Syncthing client’s log file never shows that line.
Server instance A has been started first and thus can connect to the client via local discovery. Because of the static address field, it can also connect to server instance B.
Client has been started after Server instance A. It is the only log not listing multicast.go messages.
Server instance B has been started after the client. As you can see from the logs, it fails to find any other node except for server instance A due to the static address field.
All instances have been started with STTRACE=discover,beacon. Client is Win7x64, Server is Ubuntu 14.04 ARM.
[TJ3HG] 2015/03/12 21:20:48.360823 discover.go:88: DEBUG: discover: Start local v6: listen udp ff32::5222: setsockopt: not supported by windows
[TJ3HG] 2015/03/12 21:20:48.360823 discover.go:90: INFO: Local discovery over IPv6 unavailable
It seems Go lacks IPv6 support for windows. Hence no local discovery over ipv6 for windows.
Thanks. After seeing these logs 10 times on Linux, I always skipped the first lines…
So using several instances of Syncthing on one machine, every Windows client needs to know the specific alternate IPv4 address port of each instance or one accepts the lower upload rates and uses global discovery.
It seems, my best bet it to wait until Go supports setsockopt on Windows.