Bad record MAC

Hello,

I’ve been using Syncthing for a long time now without any troubles, however recently I’ve been noticing an issue with my laptop. Due to some reason when syncing a large number of files it disconnects from the device sending the files and on that device I get this:

Dec 22 19:37:08 sync-master syncthing[2168]: [IHBDT] 19:37:08 INFO: Device R------- client is "syncthing v1.12.0" named "August" at 172.20.1.2:33287-172.20.1.178:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256

Dec 22 19:37:09 sync-master syncthing[2168]: [IHBDT] 19:37:09 INFO: Connection to R------- at 172.20.1.2:33287-172.20.1.178:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256 closed: reading length: remote error: tls: bad record MAC

My sync setup is something like:

  1. sync-master: a always on server that takes all my data
  2. desktop
  3. laptop (august)

I can transfer files to and from sync-master to my desktop without any problems, however between the laptop and the sync-master I’m always getting those errors.

All devices are directly connected to my router via ethernet. If I add some speed limit to sync-master (eg. 800 KiB/s) the laptop will sync for a longer time before disconnecting. Controversially the desktop can sync gigabytes of data without any speed limits.

Both desktop and laptop are running Windows 10 Pro with Syncthing v1.12.0 provided via SyncTrayzor. The server is Debian 10 also running the same version.

Any ideas on why this is happening?

Something is corrupting the data stream along the way. Firewalls/antivirus is the usual suspect.

1 Like

No firewalls in both computers. Well except from Windows Defender. The router itself isn’t touching the traffic, its all local.

From the desktop to the sync server it works just fine, the laptop seems to be the issue… Is there way to debug this at the laptop side?

No, there is nothing to debug in the application, as this does not happen in the application logic, it happens in Go’s TLS stack which I doubt has corruption bugs like that.

I guess you can try to redownload syncthing/verify hashes of the binary match to confirm that it’s not corrupt itself, but if that checks out, keep looking for things to switch of…

Also, you should understand which side this bad data is originating from.

I would say it comes from the laptop side… because the desktop can properly sync to the server.

I would say bad RAM, bad network card, bad network card driver, dodgy VPN software, something like that. (Technically, something that corrupts data in the TCP stream while leaving the TCP checksums correct…)

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