I am testing version 0.9.2 armv5 on a Synology NAS (node A) and connecting to a Windows machine (node B, also 0.9.2) behind the same router. The devices are configured to sync a small repo of approx 25Mb.
The nodes see each other, and they are both online with the Announce Server. The problem is that the sync on node A stops at 0% and I get the following error:
“All remaining files failed to sync. Stopping repo …”
On the node B side, I get several error messages like this: “TLS handshake: WSARecv tcp 192.168.0.79:10169: An existing connection was forcibly closed by the remote host.”
Here is the setup:
uPnP disabled on router and both nodes
Ports forwarded to node A on router: 7070 (TCP - browser port),22000 (TCP), and 21025 (UDP). Not sure this matters if both nodes on same lan.
Dynamic =Yes
Local Discovery = Yes port 21025
Global Discovery = Yes
Compression = No
Node B connects perfectly with other nodes both local and remote. So I am assuming that Node A is where the problem is. Do you have any idea how I can debug this? Thank you very much.
I checked the Firewall and AV logs on the Windows box (Node B) - nothing blocked. Then I disabled FW and AV and restarted both nodes. I am still getting the TLS error and disconnect.
I removed the repo from the Synology NAS (Node A). I restarted both nodes 5 times keeping a log of the nodes’ IP address and port as seen from the other node. I noticed that on each restart, the nodes alternated using port 22000 and a random port number. Here is a screen shot from the spreadsheet I used to capture:
Is this alternating port numbers the way the protocol intended it to be? I’m not sure what to try next to connect the Syno NAS to my other nodes.
That’s probably normal. Each node tries to connect to the other, in this case it seems both directions are viable, so you’ll see the port numbers alternating.
Is the network between these nodes somewhat less than enormously fast, do you see a “ping timeout” message on either side, and do you have some really large files to sync? (If so, this matches a known bug)
The network between the nodes is 802.11g (54Mbps). I’ve never seen a ping timeout message on either side. The repo I was syncing consisted of 10 files, in total approx. 25Mb.
When I get a chance, I am going to shut off wifi and physically connect the nodes by ethernet … 100Mbps with my hardware . I intend to create a new test repo with 1 small text file ~4kb. That should rule out timeouts or the known large file bug.
Doesn’t sound like anything related to that no, so then I’m back to “don’t know”. An “STTRACE=net,protocol syncthing” run covering a couple of those disconnects might be illuminating.
Running the STTRACE command enabled me to assume that the read/write permissions were too restrictive on the Synology repo side. I modified permissions on the repo directory to 0777 and everything connected and synced.
Thank you for helping me debug this. STTRACE is a very informative debug tool. Not a bug in syncthing.
I deleted the logs after everything started syncing. I assumed that the error was due to sloppy repo configuration by me. Sorry about that.
I will create a new test repo on the Synology NAS with the original permission settings in an effort to re-create the original connection problem. Assuming the problem re-occurs, I will rerun STTRACE, and capture the logs.
Is it OK if I PM the log to you to you as a .txt file, or must I post them in this forum?
I have re-created the connection problems and have new STTRACE logs. Apparently because I am a new user, I can’t create a PM nor upload files. I would rather not post the data dump in the forum. Please advise.
