Couldn't update through APT at all.

I was using apt-cacher-ng so I thought that might have been the problem but even after disabling it, apt kept giving me the same error:

I was also having this issue on my other server

I tried everything, and the only thing that fixed it for me was changing https to http in /etc/apt/sources.list.d/syncthing.list. A dirty fix for sure, but it worked.

I hope this saves someone else’s problem, since theres no solution to this anywhere, at all.

Edit: let me include the text version of the error so this can hopefully be found from a google search. GnuTLS recv error (-9): A TLS packet with unexpected length was received.

Googling this results in mostly cargo cult voodoo solutions (“you need to dpkg --purge git”), but I’m getting the strong feeling that the root cause is either “too old gnutls” or “machine lacks modern root CA certs” or possibly both in combination…

Similar to: Error upgrading to armhf 1.5.0~rc2 ??

Yes, clearly. Yet neither of you mention what distribution or version of it you’re running, nor whether you can for example curl from that machine. I’m running Ubuntu 16.04/18.04 in lots of places and have never seen this issue, for example, and since approximately 15% of all our users are running our Debian packages it seems to work fine for almost everyone else too. Hence my thinking that it’s either a local network problem (proxy?) or outdated machine somehow.

I’m experiencing this problem on a Raspberry PI3 with Raspian (Stretch). All packages are up-to-date. I can retrieve the ST candidate version with wget and then install it with dpkg -i.
curl fails with html output to the terminal.

Succeeds with HTML output, I guess, since that site serves HTML. So wget and curl both work, but apt-get does not for some reason. I don’t know why, but it doesn’t sound like the problem is server side at least.

Oops, I guess I did mean succeed. Attempting to install the stable version gives the same error as the release candidate on my RPI3. No problems on other machines running Ubuntu 20.04. edit: not a big deal if I can update as described with dpkg.

I recommend asking on a support communication channel of raspbian

Ummm, I have been using ST on the PI for several years, upgrading as each release candidate becomes available without any problems. With 1.5.0~rc1 the update failed as above. A second try and it succeeded! But 1.5.0~rc2 was more challenging and failed several times before I downloaded the binary and installed it with dpkg. Software from other repositories update normally with sudo apt update && sudo apt upgrade.

I rolled back the RPI3 installation using an fsarchiver backup when the RPI3 was on 1.4.2 and again the subsequent update to 1.5.0~rc2 failed with the same message.

As I said, it’s not a big deal because the dpkg method works without a problem.

Maybe there are TLS certificates that are lagging on Raspian, but everything else is up to date. Just curious!

And thanks for your great software, it’s brilliant.

So I just had a debugging session on this. Results weren’t really satisfying, but well that’s how it usually is.

First of all, I didn’t have any debian stretch installation anymore (all of my machines are either on buster or bullseye), so I quickly spun up a test VM running stretch.

After a clean install, I was successfully able to add the syncthing apt repository and was able to pull both 1.4.2 and 1.5.0-rc.2 through apt-transport-https. So I couldn’t reproduce the problem from my test machine.

However, I figured out the following:

  • It cannot be related to the certificate, because then apt-get update should already fail - which isn’t the case, right?
  • It also cannot be a general problem that happens always, because then apt-get update wouldn’t work either.

After a bit of research, it turns out that GnuTLS has had multiple issues in the past. The Ubuntu and Debian bugtracker reveal different issues with TLS packet with unexpected length was received. A few examples below:

From what I get from these reports, GnuTLS was broken multiple times in the past. The reports mention different causes, so it’s not always the same issue.

There is one report that mentions that the cause is a random padding issue, which happens either randomly or due to a proxy in between. I guess that’s what is affecting you. The fix for these issues hasn’t landed in the old GnuTLS version that is included with stretch, so I think your issues will go away if you update to buster. Or, if you have a proxy somewhere in your network, try removing that.

1 Like

@Nummer378 thanks for your efforts to debug this issue.

To confirm that sudo apt update && sudo apt upgrade work without issue and upgrade other packages.

I thought I would check again that wget also works but got this error before a second attempt succeeded:

$ wget –2020-05-01 08:22:44-- Resolving (… 2a03:b0c0:0:1010::99:8001, Connecting to (|2a03:b0c0:0:1010::99:8001|:443… connected. HTTP request sent, awaiting response… 200 OK Length: 9024674 (8.6M) [application/x-debian-package] Saving to: ‘syncthing_1.5.0~rc.2_armhf.deb’ 68%[=================================> ] 5.86M 531KB/s in 11s

2020-05-01 08:22:56 (537 KB/s) - Read error at byte 6144000/9024674 (A TLS packet with unexpected length was received.). Retrying.

–2020-05-01 08:22:57-- (try: 2) Connecting to (|2a03:b0c0:0:1010::99:8001|:443… connected. HTTP request sent, awaiting response… 206 Partial Content Length: 9024674 (8.6M), 2880674 (2.7M) remaining [application/x-debian-package] Saving to: ‘syncthing_1.5.0~rc.2_armhf.deb’ 100%[++++++++++++++++++++++++++++++++++===============>] 8.61M 434KB/s in 6.5s

2020-05-01 08:23:05 (434 KB/s) - ‘syncthing_1.5.0~rc.2_armhf.deb’ saved [9024674/9024674]

I do have a proxy on Firefox on my laptop, which accesses the PI over ssh and rdp. Turning off the proxy made no difference, the GnuTLS error persisted.

The PI is connected to my router by ethernet and there is no proxy on the router.

It looks like I need to upgrade to Buster, but it’s curious that only ST 1.5.0~rc2 update fails with this error.

Further tests:

Using wget on my laptop connected to my router and then connected through AP from my phone takes several attempt to complete the download from

Using curl:

$ curl -O % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 34 8813k 34 3008k 0 0 235k 0 0:00:37 0:00:12 0:00:25 264k curl: (18) transfer closed with 5944482 bytes remaining to read

I’m happy to test more if needed.

Right, if this didn’t work, we’d have tons of people on the forum upset about this. The fact there is a single report, yours, implies it’s a local issue. You can probably verify that from a second device in the same network whether it has a problem.

You AV/proxy/vpn/tunneling software might be behind this.

Of course, there would be howls if this was widespread.

Just now, I have succeeded in downloading the .deb file using both wget and curl on two devices.

However, when I tested earlier today with and without VPN (Mullvad), I have no AV, I’m running Ubuntu 20.04 on my laptop and Raspian Stretch on my RPI3. I moved to another networks, including mobile data with no VPN, Socks5 proxy is off, the problem persisted.

I’m guessing it was a server-side problem that is now resolved.

Thanks again for ST, you guys do a great job.

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