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:
0.0.0.0:22000, so both instances have a unique
I tried all possible combinations and nothing succeeded. Of course,
<localAnnounceEnabled> is set to
true. What am I doing wrong?
Can you provide STTRACE=discovery logs?
Can you explain or link how to do that?
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?
127.0.0.1:22000 for one and
127.0.0.1:someOtherPort on the other, I was thinking.
127.0.0.1:22000 for the first instance and for the second instance from
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 (
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
It is the second instance and has been started after the first instance on the Syncthing server. It’s configuration file is here:
The configuration file of the first instance on the Syncthing server is here:
The configuration file of the Syncthing client is here:
So you should add additional localhost addresses for the devices.
Instance one should have address for instance two:
And instance two should have addresses for instance one:
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?
Well check STTRACE=discovery on that device (and some adjacent peer you expect to discover that device), and make sure it actually has a v6 address.
This is the log file on the device. While I check other logs on adjacent peers, is it enough to check if
points to a v6 address?
Ok, you need
Is the localAnnounceMCAddr defined?
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.
Yeah, I think this is where my v6 knowledge ends.
Maybe it’s a bug? Is there a reasonable explanation why Syncthing on the client won’t use multicast.go while Syncthing on the server does?
Well I am not sure its not using it. You only post a line rather than a whole log, and it’s not clear which device it is etc.
Sorry, here are the details, logs and configs!
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.
Syncthing Server Instance A log file: http://pastebin.com/78QGvZRf
Syncthing Server Instance A config file: http://pastebin.com/8M4Qr0ZA
Syncthing Server Instance B log file: http://pastebin.com/89WyW0tn
Syncthing Server Instance B config file: http://pastebin.com/k46irnc6
Syncthing Client log file: http://pastebin.com/uQwi1MYL
Syncthing Client config file: http://pastebin.com/8gsA4JsD
Well the error message is there and clear:
[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.
Thank you for your help!
More information about Go supporting setsockopt on Windows is here: https://github.com/golang/go/issues/7174