There are multiple issues. Main questions:
- 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)
- 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:
-
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
-
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
GTMM2P
andBJGC44
.What is also buffling to me how in the UI there can be a connection between
FAMFRU
andJQBL4S
, 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)