Devices become disconnected


One windows and one linux device. The devices keep getting disconnected every few minutes. I couldn’t figure out how to enable logs on linux systemd service, but I have attached a log showing the disconnect on the windows device. They do reconnect after some time - but they used to stay connected.

syncthing.log (81.4 KB)

syncthing connects, fails to sync and then disconnects
Android arm64, version 0.14.19 loses connection and breaks sync
(Audrius Butkevicius) #2

You have to get the logs from the other side. I suspect its crashing on the other side.

(Antony Male) #3

If you started Syncthing with systemctl start syncthing@user.service, use journalctl -r -u syncthing@user.service to get the logs.

Likewise if you started Syncthing with systemctl --user start syncthing.service, use journalctl -r -u syncthing.service to get the logs.


Gotcha, thanks. Got the log from the linux device (pine64).

syncthing_pine64.7z (303.1 KB)


Actually, I’m not seeing anything in the pine64 log about the disconnection.

Edit: Sorry, learning how to read the logs. I’ve done some more debugging while looking at the logs and seeing when it disconnects. It seems like only the windows device (fuscination) reports a disconnection.

The pine64 doesn’t seem to have anything in the logs about each disconnect and in the web interface, still says they are connected.

(Antony Male) #6

It’s connected via a relay, isn’t it? It looks like the relay’s forcefully closing the connection.

(Audrius Butkevicius) #7

I can read 7zips over the phone so I don’t know whats on the other side, but it seems that first log talks about switching to tcp from relay, so it’s closing the relay connection as it succeeds to connect directly. The question is who closes the direct connection.


Okay, not sure how to fix that problem about the relay switching.

Here’s the first 100 lines of the log from the pine64 in plain text, but from what I could tell, there didn’t seem to be any indication of a disconnect there.

syncthing_pine64.log (17.4 KB)

(Audrius Butkevicius) #9

It looks like a firewall issue. We connect via a relay first, all is well, then we manage to connect directly, drop the relay connection, but the direct connection stalls, breaks and the cycle restarts.

Just for fun try disabling relays on both sides and see what happens.


With the relay turned off for both devices they are still able to connect and they also exhibit the disconnect behavior.

Pine64 syncthing_pine64_1.log (17.7 KB)

Fuscination: syncthing_fuscination.log (5.0 KB)

(Jakob Borg) #11

There’s no clear smoking gun here other than that things sent by fuscination don’t seem to reach pine64 after a while; perhaps a firewall with a very low idle timeout, perhaps something else, it’s hard to say without looking at packet traces or something.

Syncthing sends a tiny “ping” message on every active connection every 90 seconds. The “read timeout” you see in the pine64 logs means that that device hasn’t received anything from the other side in 300 seconds. That “can’t happen” unless the connection is interfered with somehow.


Just an update - this happens even on my LAN - so it would seem unlikely it’s a firewall issue. Nothing about my network topology changed recently, either.

If you can describe how to report the packet traces, I would happy to provide those.

(Audrius Butkevicius) #13

Try this:

Also in advanced settings, enable limitBandwidthInLan.


So far so good! I’m so happy! Thank you.

(Jakob Borg) #15

Erm. What’s syncthing -version say on your non-Windows device?

How do I un-like a post?

syncthing v0.14.19 "Dysprosium Dragonfly" (go1.8beta2 linux-arm64) 2017-01-10 07:50:11 UTC

Android arm64, version 0.14.19 loses connection and breaks sync
(Jakob Borg) #17


Android arm64, version 0.14.19 loses connection and breaks sync

So it’s not android specific ;). The new rate limiter doesn’t like ARM64 for some reason.

(Jakob Borg) #19

Yeah. There appears to be a multitude of interesting bugs intertwined.


If the <= really fixes this, I don’t see, why this is a problem inside the same LAN when limitBandwidthInLan is disabled.