Connection attemps do not stop, when connected across multiple local-networks (across repeaters)

There are multiple issues. Main questions:

  1. How can I prevent my devices to search each other for eternity and thereby prevent the creation of log (while still finding a connection and being connected)
  2. How to make my devices actually connect properly to each other.

These questions sound lame, if one knows that they already find each other and files can be transferred, but the devil is in the details. Maybe at the end of the day we may find that nothing is wrong the way it is, but I do have found some things that seem to be out of the ordinary to me.

My setup:

Usually, my devices can find each other. If I have observed correctly, the Windows devices usually only find each other, when the Linux Mint one is online, but they continue to find each other, when the Linux Mint goes offline I think. They eventually find each other and since I can send data to Fedora or Linux Mint first and from there to the other Windows device, this behaviour could be better, but is sufficient for my use case. I am rather concerned about the huge amount of log that is generated, though. I experience multiple gigabytes of data being created on my Windows 10 home partition, within hours and have the suspicion that Syncthing MIGHT be responsible. These gigabytes also vanish randomly. Have not found the culprit yet.

The problems:

  1. My local device still tries to connect to my remote device JQBL4S, even though the remote is offline. Will it ever stop?

    The behavior happens when I turn off JQBL4S (Linux Mint) or just exit Syncthing.

    2022-04-04 14:08:53 Enabled debug data for "connections"
    2022-04-04 14:09:05 Listen (BEP/tcp): connect from "IP-Adress IPv4 Nr.1"
    2022-04-04 14:09:06 Failed to exchange Hello messages with GTMM2PM at 192.168.178.22:22000-"IP-Adress IPv4 Nr.1"/tcp-server/TLS1.3-TLS_CHACHA20_POLY1305_SHA256: write tcp 192.168.178.22:22000->"IP-Adress IPv4 Nr.1": write: connection reset by peer
    2022-04-04 14:09:08 Connection loop
    2022-04-04 14:09:08 Resolved device C6M5CQJ addresses: []
    2022-04-04 14:09:08 Resolved device FKJEGNS addresses: []
    2022-04-04 14:09:09 Resolved device JQBL4SA addresses: [quic://192.168.178.39:22000 quic://"IP-Adress IPv4 Nr.1":22000 quic://["IPv6 Nr. X"]:22000 quic://["IPv6 Nr. Y"]:22000 tcp://192.168.178.39:22000 tcp://"IP-Adress IPv4 Nr.1":22000 tcp://"IP-Adress IPv4 Nr.1":62295 tcp://"IP-Adress IPv4 Nr.1":62408 tcp://["IPv6 Nr. X"]:22000 tcp://["IPv6 Nr. Y"]:22000]
    2022-04-04 14:09:09 Not dialing JQBL4SA via tcp://192.168.178.39:22000 as it's not time yet
    2022-04-04 14:09:09 Not dialing JQBL4SA via tcp://"IP-Adress IPv4 Nr.1":22000 as it's not time yet
    2022-04-04 14:09:09 Not dialing JQBL4SA via tcp://"IP-Adress IPv4 Nr.1":62295 as it's not time yet
    2022-04-04 14:09:09 Not dialing JQBL4SA via tcp://["IPv6 Nr. X"]:22000 as it's not time yet
    2022-04-04 14:09:09 Resolved device J6IIF6Y addresses: []
    2022-04-04 14:09:09 Resolved device SVA7MK7 addresses: []
    2022-04-04 14:09:09 Resolved device WEALBVQ addresses: []
    2022-04-04 14:09:09 Resolved device 3CBJJFD addresses: []
    2022-04-04 14:09:09 dialing JQBL4SA tcp://"IP-Adress IPv4 Nr.1":62408 prio 10
    2022-04-04 14:09:09 dialing JQBL4SA tcp://["IPv6 Nr. Y"]:22000 prio 10
    2022-04-04 14:09:09 dialing JQBL4SA tcp://["IPv6 Nr. Y"]:22000 error: dial tcp ["IPv6 Nr. Y"]:22000: connect: network is unreachable
    2022-04-04 14:09:11 dialing JQBL4SA tcp://"IP-Adress IPv4 Nr.1":62408 error: dial tcp "IP-Adress IPv4 Nr.1":62408: connect: no route to host
    2022-04-04 14:09:11 failed to connect to JQBL4SA 10
    2022-04-04 14:09:11 dialing JQBL4SA quic://192.168.178.39:22000 prio 99
    2022-04-04 14:09:16 dialing JQBL4SA quic://192.168.178.39:22000 error: dial: timeout: no recent network activity
    2022-04-04 14:09:16 failed to connect to JQBL4SA 99
    2022-04-04 14:09:16 dialing JQBL4SA quic://"IP-Adress IPv4 Nr.1":22000 prio 100
    2022-04-04 14:09:16 dialing JQBL4SA quic://["IPv6 Nr. X"]:22000 prio 100
    2022-04-04 14:09:16 dialing JQBL4SA quic://["IPv6 Nr. Y"]:22000 prio 100
    2022-04-04 14:09:16 dialing JQBL4SA quic://["IPv6 Nr. X"]:22000 error: dial: INTERNAL_ERROR: write udp [::]:22000->["IPv6 Nr. X"]:22000: sendto: network is unreachable
    2022-04-04 14:09:16 dialing JQBL4SA quic://["IPv6 Nr. Y"]:22000 error: dial: INTERNAL_ERROR: write udp [::]:22000->["IPv6 Nr. Y"]:22000: sendto: network is unreachable
    2022-04-04 14:09:21 dialing JQBL4SA quic://"IP-Adress IPv4 Nr.1":22000 error: dial: timeout: no recent network activity
    2022-04-04 14:09:21 failed to connect to JQBL4SA 100
    2022-04-04 14:09:21 Next connection loop in 20s
    2022-04-04 14:09:31 Listen (BEP/tcp): connect from "IP-Adress IPv4 Nr.1":62415
    2022-04-04 14:09:31 Failed to exchange Hello messages with BJGC44M at 192.168.178.22:22000-"IP-Adress IPv4 Nr.1":62415/tcp-server/TLS1.3-TLS_CHACHA20_POLY1305_SHA256: write tcp 192.168.178.22:22000->"IP-Adress IPv4 Nr.1":62415: write: connection reset by peer
    
  2. Digging deeper I noticed that the Windows devices seemingly cannot be found by my Linux Mint, even though they are connected. The logs are a mess. The most interesting thing I found was this line on my local Windows 10 device (GTMM2P):

    2022-04-04 16:58:38 dialing BJGC44M tcp://"ipv4 Nr.4 (external IP of Router)":22000 error: unexpected device id, expected BJGC44M got F4MFRUP
    

    There are similar lines in the log on Linux Mint (JQBL4S). Every loop switches the expected device id between GTMM2Pand BJGC44.

    What is also buffling to me how in the UI there can be a connection between FAMFRU and JQBL4S, see here:

    even though the log of FAMFRU shows this line:

    2022-04-04 19:02:32 Failed to exchange Hello messages with JQBL4SA at 192.168.178.22:22000-"external ipv4 adress of my router":55558/tcp-server/TLS1.3-TLS_CHACHA20_POLY1305_SHA256: write tcp 192.168.178.22:22000->"external ipv4 adress of my router":55558: write: connection reset by peer`
    

    Here full logs:

    GTMM2P log with debug connections and dialer while remote is turned off.txt (24.8 KB)

    log file for JQBL4S with debug log for connections and dialer after restarting syncthing.txt (31.9 KB)

    Debug Log of FAMFRU with connections, dialer and nat debugging activated while all devices are running.txt (28.2 KB)

Is this normal, expected behaviour?

Ps. related threads:

Edit: Meanwhile, I have set my router to assign not random ipv4 adresses, but always the same ones to my two repeaters.

You have debug logging enabled, that’s why there is all this logging.

I suggest you reduce the problem space to just two devices - I am not really following all the pieces here.

Generally: If devices get discovered (many addresses hown as in one of your screenshots) but there’s various errors (timeouts, …), then host firewall is a likely suspect.
If no addresses (or no reasonable ones) are shown, you likely have a discovery problem. E.g. repeaters/routers not forwarding multicast packets for localy discovery.

Also if you have remote (WAN) devices, and multiple devices behind the same router listening on the same port these “expected X got Y” errors can happen, the solution is to assign different listening ports to different devices in the LAN.

I also had continuous logging (albeit less), when debug logs were turned off.

Funny thing though, right now I was not able to reproduce (for this and the other test down below, BJGC44 was turned off, so it was only a 3 device setup). I will do some more tests and report back later or one of these days.

Yeah, could be. Just now, when I started my Linux Mint Syncthing I was not able to discover GTMM2P. But as soon as I restarted Synctrayzor on GTMM2P, it connected. It looks like the discovery has to be an outgoing call from Windows. I really tried to allow Syncthing/Synctrayzor in Windows Firewall, but alas…

I will try to assign different listening ports. Thank you!

Is your network in Windows set to private? It needs to be in order to allow direct connections.

It is public, but Syncthing is set to private.

If you’re speaking about the screenshot above, it only means that Syncthing is allowed to connect on a private network. If the network itself is set to public though, the setting has no effect. I’m not sure if allowing just Syncthing to connect on public networks will be enough for the OS to allow direct connections inside the application.

From my experience, unless you’ve got a good reason not to do so, switching the network to private usually fixes most of connectivity issues with Windows devices.

Sorry for the German. Can’t change my OS language that easily, but this seems pretty clear to me that incoming packets are allowed.

But will do some more tests one of these days. Also with firewall set to private.

Just for the record, when speaking about setting the network to “private”, I’m thinking about https://support.microsoft.com/windows/make-a-wi-fi-network-public-or-private-in-windows-0460117d-8d3e-a7ac-f003-7a0da607448d, not the firewall.

Aaah, thanks. Ok, yes, I changed the network to “private” now on my device GTMM2P.

Made no difference though. Sorry to keep this a 3 device setup, but I do not have control over the device BJGC44 atm.

The following test used this device setup:

  • F4MFRU on
  • JQBL4S off
  • GTMM2P on → network set to private
  • BJGC44 on → network may or may not be set to private

Here the logfile: 2022-04-05 FAMFRU Standard Log, while GTMM2P and BJGC44 are running.txt (12.8 KB)

You can see it repeatedly tries to attempt to reconnect, even though the connection is already established.

  • Meanwhile, both on GTMM2P AND on F4MFRUP, in the UI, they are seen to be connected
  • On GTMM2P logs are NOT continuously created. Nothing seems out of the ordinary.

Did you already change the listen ports? I have an idea what’s happening: Probably GTMM2P is trying to connect to one of the other devices, but all of those attempts are routed to F4MFRU which then fails somehow with the not very helpful info message. The way we handle this isn’t particularly nice really. Anyway, syncing should be working just fine except for the needless logging, right?

I have not changed the listen ports yet.

Correct, I can sync things and everything seems to work fine. When they don’t see each other, I restart Syncthing on the Windows devices, which results in them usually connecting. Fair enough. Only thing is the useless log (and the useless attempts at reconnecting). At least this is what I experienced during this test

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