Global Discovery getting priority over Local Discovery?

Testing between two Linux Laptops on same Lan segment. Local Firewalls off on both devices. Addresses set to "Dynamic" Syncthing v0.13.5

If I shutdown Syncthing on one of the laptops, then start it again, the laptops reconnect via local discovery.

From the log of one of them:

192.168.112.101:22101 - 192.168.112.104:46471 (TCP (Server))

But if I restart Syncthing on either laptop, the laptops re-connect via global discovery

From the log of one of them:

192.168.112.101:40382 - 59.167.nnn.nn:22104 (TCP (Client))

I can repeat this any number of times.

Shutdown/Start Syncthing -> Local Discovery

Restart Syncthing -> Global Discovery

Turning off Global Discovery then forces all devices to connect via Local Discovery, even on a restart, so Local Discovery is working.

Config file has:

    <localAnnouncePort>21027</localAnnouncePort>
    <localAnnounceMCAddr>[ff12::8384]:21027</localAnnounceMCAddr>

Why are reconnections after restart preferring Global Discovery over Local Discovery? Obviously it is much better to connect via the local lan if possible rather than going up through the internet.

Local discovery is prioritized. However answers may not be available for a while after startup, so global gets there first. We used to have a connection delay for this reason but maybe that got lost over time. Just to confirm - if you pause and resume a device (to force it to be disconnected), I assume it connects via the local address afterwards?

Just ran it with an STTRACE=discovery

and, remarkably, it connects via local discovery! Likely because strace output to the terminal slows it down so seems liek;y a timing issue…

Will now try with pause and resume.

Yes, indeed, Pause/Resume closes the connection

then re-establishes it as a local network connection.

Works both against Linux laptops and Android devices.

If you can still reproduce it with a normal restart, give this build a spin and see if it resolves it:

https://build.syncthing.net/job/syncthing-pr/2383/artifact/

Thanks Jakob.

But apologies for a stupid question: this is not something I have done before.

Can I just physically replace the files

/lib/systemd/system/syncthing-resume.service

/lib/systemd/system/syncthing@.service

/usr/bin/syncthing

/usr/lib/systemd/user/syncthing.service

with the files from the relevant .tar.gz? (for me: syncthing-linux-amd64-v0.13.5+11-ga9680e2.tar.gz).

(I could also install the syncthing_0.13.5+11-ga9680e2_amd64.deb but that would affect my apt records and I would have to uninstall/reinstall syncthing to go back to using the repos)

If you just want to test it, stop the system-installed Syncthing, download it, put it in your home folder, and run it. It will use the same database.

Thanks very much, appreciated. Will do it tomorrow - past my bedtime now (currently in Sydney).

1 Like

Thanks. Test this one instead: https://build.syncthing.net/job/syncthing-pr/2386/artifact/

Tried syncthing-linux-amd64-v0.13.5+13-g56d1fee.tar.gz

Works well.

Assume:

A = laptop with test Syncthing v0.13.5+13-g56d1fee

B = laptop with test Syncthing v0.13.5+13-g56d1fee

C = Android with Syncthing v0.13.2

Some notes

  1. Restart of A or B now always uses local discovery between A & B
  1. Restart of A now almost always uses local discovery between A & C
  1. Restart of C uses global discovery, so the timing changes are local to the instance of Syncthing on A, not over the network. I assume this is intended behaviour.

re 3: (but note: sometimes even a cold start of Syncthing v0.13.2 on Android uses global discovery, whereas on Laptops using v0.3.15 cold start always uses local discovery).

Hope this is helpful. Let me know if you need anything further.

1 Like

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