Syncthing does not find Connection to Clients on Server with 2 NICs in same LAN

Hello.

I have a problem when a machine has two network cards in the same subnet. Example scenario:

Server_A with two NICs
IP_NIC_1: 192.168.1.1
IP_NIC_2: 192.168.1.2
Syncthing is running and has been configured to talk to Client_B.
OS: Windows 10

Client_B has IP: 192.168.1.3
OS: tested with macOS, Linux, QNAP appliance

Everything works until Server restarts. After restart, neither Client nor Server find each other.
The Syncthing GUI “remote device name” for the server in the client GUI is something like “ABCDEF” instead of “Server_A”. The same is true in the Syncthing GUI on the server side, where the remote device name is “GHIJKL” instead of “Client_A”.
The situation does not change over time.
Local discovery is activated and has worked flawlessly in the past.

Funny thing though: it is possible to click on “Add Remote Device” and add the other machine by clicking on the provided device id.
My understanding was, that this needs a trust relationship. If this is correct, then there seems to be a connection somewhere…
Adding the (same) device to the client (again) works. The folders to share need to be selected again as well - it is like a totally new device. After that, syncing works, but since it is a new client, everything and the kitchen sink has to be indexed, taking a long time and doubling the space needed (from 2GB to 4GB here).

Questions:
Has somebody experience with this kind of setup? Is this by design? is there a secret setting to “prefer” a NIC?

Thanks!

Do not think this has anything to do with the two network cards. Syncthing data is located here:

/Users/USER/AppData/Local/Syncthing

Get everything setup once more and take a look at the config.xml file in Notepad/Wordpad. Then restart your machine. If everything works great. If not check the config.xml file again and see what is in there. If everything is okay the issue is likely with Syncthing starting as a different user. How does Syncthing start on the server (scheduled task or an shortcut in “Startup Programs”?)

Restarts should not influence discovery. A needs to be trusted on B, and B needs to be trusted on A for syncthing to work, where trusted means the device needs to be added on either side.

I made a long post about not being a n00b and stuff, but honestly, not worth it. If the devs don’t think this is something they want to dedicate their sparse time to look into, thats okay with me. This behaviour is certainly uncommong and it has now been documented, if anybody come across it later. It was not a one time experience, as I would never open a thread for that. But as I cannot forcibly write down steps to recreate, it would be hard to analyze. I’ll just watching it, maybe there is more detail to add at some point in the future (the servers reboot only twice a year or so).

I am not sure I understand what answer you expect. Your explanation doesn’t make much sense either as device names should be saved in the config and should not disappear and discovery does announcements over all interfaces and by default syncthing listens on all interfaces so restart should have no meaning.

and should not disappear and discovery does announcements over all interfaces and by default syncthing listens on all interfaces so restart should have no meaning.

Exactly. And yet this has happened.
Since I can’t explain it, I wrote it down and asked my questions. Your answer was just a statement, nothing I could work with. And schnappi’s answer was basically “don’t worry if it doesn’t happen again” apart from a hint about different users.

Well, that wasn’t the first issue and it certainly is not the last. I just won’t bother documenting erratic behaviour anymore. Why make the effort? Let other be dissed.

Well, you enable debugging facilities for discovery, connections etc and see if you spot something being different. Also I’d check the developer console in chrome for exceptions perhaps explaining why device names are not shown.

Do want to help. Still do. The responses (or at least mine) was severely misunderstood. Agree that @AudriusButkevicius response makes no sense (rather serves no purpose), but at the same time the initial question was not concisely or clearly written and my similarly complicated response was misunderstood nor was it acted on to address the issue. But understand. The issue is tough and complicated to type out as was and is the likely solution. @AudriusButkevicius always responds very quickly and seems to want to help many users. All this being said, forget about those responses.

After everything is setup and working would recommend restarting to see if everything is still working. Assuming Syncthing stops working yet again after a restart done on purpose for problem solving one should then check the config.xml file in the Syncthing data location of the logged in user and see if the shared folders previously are still listed in the config.xml file. If they are not Syncthing is starting as another user or pulling/ using data from a different location than:

/Users/USER/AppData/Local/Syncthing

Additionally if the config.xml file in the above location does not have data in it about the shared folders even when everything is working this would indicate that Syncthing is using a different data folder location. This is why would check the config.xml file prior to restarting as well after everything is setup as desired. Be careful though. Since have setup Syncthing multiple times already you may see a config.xml file that looks like it is correct. Check the folders ID’s in the config.xml and make sure that it corresponds to the folder ID’s listed in the GUI to match up a config.xml file with a running instance.

A restart isn’t purely necessary to rule out Syncthing being run as a different user or using a different data location but it is a very clear, easy, and absolute way to ensure that the Syncthing task is completely stopped before restarting. One could alternatively to restarting kill the Syncthing task and restart Syncthing in the same way in which it would start after a restart before checking the config.xml file.

The reason to go through this task and check the config.xml file is to try to decipher where Syncthing is storing it’s data while it is running. If Syncthing starts either with a different user or with a different data location anything previously setup will not work and it would make very good sense that Syncthing would function like a brand new instance where everything can be re-added and re-indexed from scratch.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.