five minutes to reconnect when a device changes network

Feature
1

I have been testing Syncthing for a few days - first thank you for a truly nice program that handles well a complicated distibuted problem.

Scenario: Laptop S77lx1 and Android S3Cym11 are on the same LAN They connected via local discovery. I turn off wlan on Android S3Cym11 Later: I turn on again wlan on Android S3Cym11

Result In both cases, the devices takes 5 minutes to reconnect.

The process When Android S3Cym11’s network changes from wlan to mobile data Laptop s77lx1’s log shows the following typical entries:

[ZRTMZ] 11:40:43 INFO: Connected to already connected device (5NCNIVS-…) [ZRTMZ] 11:41:51 INFO: Connected to already connected device (5NCNIVS-…) [ZRTMZ] 11:42:57 INFO: Connected to already connected device (5NCNIVS-…) [ZRTMZ] 11:44:10 INFO: Connected to already connected device (5NCNIVS-…) [ZRTMZ] 11:45:13 INFO: Connected to already connected device (5NCNIVS-…) [ZRTMZ] 11:45:52 INFO: Connection to 5NCNIVS-… closed: read timeout [ZRTMZ] 11:46:24 INFO: Established secure connection to 5NCNIVS-… at 192.168.112.101:22101-49.182.143.99:2197 (TCP (Server)) [ZRTMZ] 11:46:24 INFO: Device 5NCNIVS-… client is “syncthing v0.13.2” named “S3Cym11”

When Android S3Cym11’s network changes from mobile data back to wlan Laptop s77lx1’s log shows the following typical entries:

[ZRTMZ] 19:08:16 INFO: Connected to already connected device (5NCNIVS…) [ZRTMZ] 19:09:18 INFO: Connected to already connected device (5NCNIVS…) [ZRTMZ] 19:10:21 INFO: Connected to already connected device (5NCNIVS…) [ZRTMZ] 19:11:22 INFO: Connected to already connected device (5NCNIVS…) [ZRTMZ] 19:12:24 INFO: Connected to already connected device (5NCNIVS…) [ZRTMZ] 19:13:30 INFO: Connected to already connected device (5NCNIVS…) [ZRTMZ] 19:13:54 INFO: Connection to 5NCNIVS… closed: read timeout [ZRTMZ] 19:14:11 INFO: Established secure connection to 5NCNIVS… at 192.168.112.101:40384-192.168.112.102:22102 (TCP (Client)) [ZRTMZ] 19:14:11 INFO: Device 5NCNIVS… client is “syncthing v0.13.2” named “S3Cym11”

Configuration

  • Laptop S77lx1 running Kubuntu 14.40, UFW disabled for testing, Syncthing v0.13.5. Sync Protocol Listen Addresses = tcp4://0.0.0.0:22101 , On the lan is has address 192.168.112.101
  • Android S3Cym11 running Cyanogenmod, Syncthing v0.13.2. Sync Protocol Listen Addresses = tcp4://0.0.0.0:22102 , On the lan is has address 192.168.112.102
  • In S77lx1, address of S3Cym11 is “dynamic”
  • In S3Cym11, address of S77lx1, i tried both “dynamic” and a ddns address - Same Result.
  • Router ports appropriately forwarded.

Sensitivity Notes The time to reconnect was the same whether:

  • S3Cym11 was going onto or going off the Lan.
  • there were changes made on S77lx1 or the S3Cym11 synced folders did not change.

Key Point / Question Seems there are two parameters, one about 60 seconds and one about 5 times that are used before a link is realised to be down and re-established. Can I alter these parameters?

I can see the parameter reconnectionIntervalS = 60s but that is for disconnected devices.

(ps: please excuse difficult to read formatting. bulleted lists and numbered lists dont seem to do line changes. All my end-of-lines disappear!)

2

The five minute delay is the discovery cache time. It’s not currently user adjustable.

3

Understand, thanks. Likely the sort of parameter that could cause all sorts of systemic side-effects if altered.

So instead I try to find a way to force a device rescan.

Folder Rescan on the Laptop does not work; Restarting Syncthing on the Android does not work - still takes 5 minutes to connect; Restarting Syncthing on the Laptop does work - causes a connection to be established in about a minute.

The problem is the usual scenario is you have walked out the door with the Android, and so no longer have the ability to restart Syncthing on the Laptop.

At the moment you can force a rescan of individual shared folders or all folders (Rescan All). Would you consider a command to

Rescan Devices

similar to the rescan folders command?

4

Just wait 5 minutes, whats the big deal?

5

(chuckle) I’m no doubt older than you - perhaps I don’t have as many “5 minutes” left as you.

Also, at the moment the gui shows the other device is connected at the old address for 5 minutes, when in fact it has moved. This can be misleading.

In fact, the above was a testing scenario just to illustrate. In fact I have multiple sub-lans and multiple Androids and like to keep things reflecting their true state as soon as possible. Just my nice tidy character, for which I apologise :wink:

6

So I think this 5 minute window of us thinking we are connected comes from TCP, rather than syncthing. We could lower the keepalives but then we risk timeouts and disconnects on poor connections or week devices.

7

Yes, I understand it would be very complicated/risky to try to make this automatic. But a manual “Rescan Devices” available to each user for when he is changing networks / walking out the door should not be so dangerous.

(also, I agree it is not a big deal - just a nice to have).

8

There is no such thing as rescan devices. As far as we are being told by TCP, we are still connected, so there is nothing to rescan. Yes, yo could send a message to verify if you are still connected, but even that needs a timeout of some form.

9

If it’s in fact the detection of the device disappearing, that comes down to our pings over the connection which is also a few minutes, maybe five, yes. Also not adjustable. :slight_smile: It was, but you don’t want to tweak it down or you’ll get spurious connection failures.

10

In fact I think there is sort of such a thing as Rescan Devices - you can do it by restarting Syncthing on the Laptop. As I mentioned, restarting Syncthing forces it to notice the other device is disconnected, then reconnects to the wandering device in 1 minute.

But for reasons I am not clear on (different Syncthing versions maybe?) restarting Syncthing doesn’t force the reconnect when done from the Android.

11

Syncthing daemon and the app are decoupled, so you explicitly have to restart the daemon, rather than the app.

Not sure how you do that though

12

On the laptop I am running per user, so Syncthing is not daemonized. So clicking “Restart” from the gui does in fact do a restart of the syncthing process (new process id)

Not sure how it works on the Android - but restarting Syncthing, shutting down and then restarting Syncthing, and even rebooting the Android does not force the rescan, and certainly rebooting would restart any daemon. So maybe it is something else peculiar about Android, or maybe a version feature (v0.13.5 on laptop, v0.13.2 on android).

13

another Android peculiarity: if you shut down Syncthing, then change the connection (eg wlan to mobile data), then restart Syncthing, it immediately reconnects correctly! Must do a rescan.

But if you change the connection type, then shutdown and restart Syncthing, it takes the usual 5 minutes.

Anybody who can explain that might give the clue as to how to force a rescan on Android.

14

Did you shut down the sycnthing daemon or thr app?

15

Have you tried pausing the device? Does this sever the connection so it is recreated on the new network when you resume it?

16

@AudriusButkevicius As mentioned above, On the laptop I am running per user, so Syncthing is not daemonized. So clicking “Restart” from the gui does in fact do a restart of the syncthing process (new process id)

@kluppy tried it, doesn’t sever the connection.

17

What Works and Why

Let B = the device changing networks;

A = a stable device, no network change.

What Works & Why: Shutdown then Change Network

On device B, shutdown Syncthing, change networks, restart Syncthing.

Why: shutting down sends a signal to A (A’s log shows as EOF) which causes A to close its connection.

Starting B then establishes a new connection at the new network address.

What Doesn’t Work and Why - Restart

When B changes networks and then does a Syncthing restart, it tries to reestablish the connection to A, but A rejects the connection attempts for 5 minutes as ‘confusing’, then gives up, closes the old connection and establishes a new one.

B’s log:

V3VRR] 17:33:26 INFO: Established secure connection to ZRTMZYA- at 192.168.114.104:45157-59.167.128.35:22101 (TCP (Client)) V3VRR] 17:33:26 INFO: Established secure connection to ZRTMZYA- at 192.168.114.104:45157-59.167.128.35:22101 (TCP (Client)) [V3VRR] 17:33:26 INFO: Device ZRTMZYA-4 client is “syncthing v0.13.5” named “s77lx1” [V3VRR] 17:33:26 INFO: Connection to ZRTMZYA- closed: EOF

A’s log:

Connected to already connected device (V3VRRNY-)

So Possible Method

‘Reset Device’ button, creating a reset packet that, sent from B,

would say to A “don’t ignore this connection attempt, I really have changed networks”.

On receiving this connection reset packet, A would close the old connection and allow it to be reestablished.

BTW

I am not suggesting this be done, and you probably already have a reset protocol Just offering it as a thought for when you look at the possible enhancements in this area in the future.

For myself, I’ll just try to remember to shutdown Syncthing before a device (usually an Android) changes networks.

1 Like
18

To be honest, I think that nobody apart from you is really bothered by/care about this.

If you want to fix this, feel free to make a pull request, yet I can’t imagine a sensible way to do this.

I think the core issue is that androids network stack is customized enough that it deliberately delays things such as connections breaking due to the device being mobile and being exposed to these things much more than a device with a fixed connection, and any attempt to fix this is more or less tilting at windmills.

19

Understand and of course no problem.

But a clarification: it is not just an android problem:

I tested today between 2 (Linux) laptops, moving one of them between different lans.
same issue, same solution.

As for my making “Pull Requests”, well if I ever manage to grow my brain big enough to become a programmer…will have to eat a lot more veges than I do. :wink:

20

I can see similar “problems”.

But I will add my situation: Laptop is sync with PC in work. When I am at home I am connecting over VPN to work. Everything is working well, laptop and PC are see each other, I can see that in web gui. But when file is change on any node the change is not sync to another node. I using syncthing-inotify and rescan interval is set to 84000. Usually clicking rescan manually help. But next day I am caming to work and same situation. Looks that changes are not transfer byt web gui is saying that laptop and PC are sync and up to date.