Can't connect from one macOS machine, but works from another

I have two macOS laptops running Syncthing-macos 1.7.0-1. They talk to each other just fine.

One talks to and synchronizes with a third machine - the richb-Vostro-3550 machine running Ubuntu 18.04. The other macOS laptop does not, but gives an error message, No compatible QUIC version found. We support [QUIC WG draft-28], server offered [0xff000016 0xyadaea4a] (see screen shot below).

Any thoughts on diagnosing why the one computer works, and the second does not? I attach the log messages below the screen shot. What other diagnostic information could I provide? Many thanks.

The logs show:

2020-07-10 21:18:57 Single thread SHA256 performance is 60 MB/s using minio/sha256-simd (58 MB/s using crypto/sha256).
2020-07-10 21:18:58 Hashing performance is 51.36 MB/s
2020-07-10 21:18:58 Overall send rate is unlimited, receive rate is unlimited
2020-07-10 21:18:58 Using discovery server
2020-07-10 21:18:58 Using discovery server
2020-07-10 21:18:58 Using discovery server
2020-07-10 21:18:58 Ready to synchronize "LymeFiber_Files" (ntqbp-wqebt) (sendreceive)
2020-07-10 21:18:58 Relay listener (dynamic+ starting
2020-07-10 21:18:58 Ready to synchronize "LLL Network Stuff" (wqs9v-nufj5) (sendreceive)
2020-07-10 21:18:58 ...
2020-07-10 21:18:58 QUIC listener ([::]:22000) starting
2020-07-10 21:18:58 TCP listener ([::]:22000) starting
2020-07-10 21:18:58 Completed initial scan of sendreceive folder "LymeFiber_Files" (ntqbp-wqebt)
2020-07-10 21:18:58 Completed initial scan of sendreceive folder "LLL Network Stuff" (wqs9v-nufj5)
2020-07-10 21:18:59 GUI and API listening on
2020-07-10 21:18:59 Access the GUI via the following URL:
2020-07-10 21:18:59 My name is "Richs-MBP-Pro.lan"
2020-07-10 21:18:59 Device AEYZNCU-MLESDL2-QP7CXYO-3HPVITF-6E5656C-Q2HVBBD-UQTVFLD-ZOVBSA5 is "richb-Vostro-3550" at [dynamic]
2020-07-10 21:18:59 Device UZXFASV-LBGQA2R-E6VOFSA-QLAR4NB-FU3ULIQ-EOTDTA4-2IN4UYT-N2YNZQD is "RichsDeLatitude.lan" at [dynamic]
2020-07-10 21:19:09 Established secure connection to AEYZNCU-MLESDL2-QP7CXYO-3HPVITF-6E5656C-Q2HVBBD-UQTVFLD-ZOVBSA5 at
2020-07-10 21:19:09 Device AEYZNCU-MLESDL2-QP7CXYO-3HPVITF-6E5656C-Q2HVBBD-UQTVFLD-ZOVBSA5 client is "syncthing v1.4.2" named "" at
2020-07-10 21:19:10 Connection to AEYZNCU-MLESDL2-QP7CXYO-3HPVITF-6E5656C-Q2HVBBD-UQTVFLD-ZOVBSA5 at closed: reading length: EOF
2020-07-10 21:19:10 Established secure connection to UZXFASV-LBGQA2R-E6VOFSA-QLAR4NB-FU3ULIQ-EOTDTA4-2IN4UYT-N2YNZQD at
2020-07-10 21:19:10 Device UZXFASV-LBGQA2R-E6VOFSA-QLAR4NB-FU3ULIQ-EOTDTA4-2IN4UYT-N2YNZQD client is "syncthing v1.7.0" named "RichsDeLatitude.lan" at
2020-07-10 21:19:13 Detected 1 NAT service
2020-07-10 21:19:18 quic:// detected NAT type: Port restricted NAT
2020-07-10 21:19:18 quic:// resolved external address quic:// (via
2020-07-10 21:19:44 Joined relay relay://

Your Vostro Syncthing is older (1.4.2) and the quic library we’re using is evolving and somewhat unstable. I guess it changed in an incompatible manner. The other connection succeeds because it’s using tcp or relay instead of quic. Perhaps you can arrange your firewalls to permit the tcp connection.

Thanks for the speedy response. After I posted this message, I wondered if the 1.4.2 version might be causing a problem. I will update the Vostro client.

But… Both the other laptops (Rich’s MBP and RichsDelLatitude.lan) were on the same subnet (in fact, both on the same desk) so I’m not sure what might have been causing the difference in behavior. (I do run LittleSnitch on Rich’s MBP, but it is set to allow all outgoing connections.)

Other thoughts? Thanks.

Updating the Linux peer solved the problem.

$ syncthing -version
syncthing v0.14.43-ds1 "Dysprosium Dragonfly" (go1.9.3 linux-amd64) debian@debian 2018-02-06 04:01:09 UTC [noupgrade]
1 Like

PS & OT: @calmh Does this version of Discourse (the forum software) offer the ability to mark a response as a solution? I have seen it in other Discourse forums, and it would have been helpful to indicate that I found a solution to this problem. Thanks.

1 Like

We don’t have that plugin, no. We could, I’m not 100% convinced of the value and there is some amount of clutter to it, I think…

A perfect answer. Never implement something because one person asks for it :slight_smile: If a groundswell arises, then it’s worth the clutter. Thanks.

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