Devices become disconnected

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.

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

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)

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)

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.

Try this:

Also in advanced settings, enable limitBandwidthInLan.

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

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

1 Like

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

1 Like

Bingo.

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

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.

because we wrap everything in wrapppers regadless, and the is lan check is done on every read/write.

Makes sense (I guess). Just disabled the limitBandwidthInLan setting and still the same (0-> no sync, 102400 -> sync).

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