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…
Yes, clearly. Yet neither of you mention what distribution or version of it you’re running, nor whether you can for example curl https://apt.syncthing.net/ 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.
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.
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.
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.
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.
