On 3/4/22 15:39, Undiscussed Horrific Abuse, One Victim of Many wrote:

Was stuck with this error doing a casual activity:

Downloading android ndk...                                    curl --fail --retry 3 -o ndk.zip https://dl.google.com/android/repository/android-ndk-r23b-linux.zip <https://dl.google.com/android/repository/android-ndk-r23b-linux.zip>                                           % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current             Dload  Upload   Total   Spent    Left  Speed  88  691M   88  609M    0     0  67.2M      0  0:00:10  0:00:09 0:00:01 63.9M          curl: (56) OpenSSL SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption fail ed or bad record mac, errno 0

The error means the ssl stream has been mutated, possibly by a third party. Note: it's hard for me to believe that, I kind of just feel it as paranoid fear. I got it every time I tried the download, at about the same amount into the stream.

It could be third party interference. It could also be your network interface (wired or wireless) failing by flipping bits at that point every time. I have had network interfaces fail this way; this is why I am currently using a USB 2.0 Ethernet adapter on my laptop and not using the built-in Ethernet.

I think there are better solutions for routing, like cjdns or something, where connects are solid and prevent such things. Not set up with them.

$ host dl.google.com <http://dl.google.com> dl.google.com <http://dl.google.com> has address 142.250.80.110 dl.google.com <http://dl.google.com> has IPv6 address 2607:f8b0:4006:80d::200e

I went on the web to get other information on the ip address of dl.google.com <http://dl.google.com> and ended up at whatismyipaddress.com <http://whatismyipaddress.com>, which also has host lookup.  It said the ip address was 142.250.72.238 . Since it starts with the same two numbers, I figured it was just some load balancing system.

$ cat /etc/resolv.conf nameserver 8.8.8.8 nameserver 208.67.222.222 nameserver 1.1.1.1 nameserver 84.200.69.80

I tried each nameserver in sequence like: $ host dl.google.com <http://dl.google.com> 8.8.8.8 for each one.

The first three gave the same ip address that fails for me, each request, which seems strange to me for a load balancing system. The fourth gave a different ip address. I have 172.217.19.238 in my scrollback history but presently am getting 142.251.36.14 .

I moved this nameserver to the top of my list and the download finally completed successfully. This could be a coincidence, but didn't seem one at the time.

As of a few minutes ago this is what I get for reference: skquinn@********:~$ host dl.google.com 9.9.9.9 Using domain server: Name: 9.9.9.9 Address: 9.9.9.9#53 Aliases: dl.google.com has address 172.253.124.91 dl.google.com has address 172.253.124.136 dl.google.com has address 172.253.124.190 dl.google.com has address 172.253.124.93 dl.google.com has IPv6 address 2607:f8b0:4002:c08::5b dl.google.com has IPv6 address 2607:f8b0:4002:c08::88 dl.google.com has IPv6 address 2607:f8b0:4002:c08::be dl.google.com has IPv6 address 2607:f8b0:4002:c08::5d skquinn@********:~$ host dl.google.com 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: dl.google.com has address 142.251.45.46 dl.google.com has IPv6 address 2607:f8b0:4000:800::200e skquinn@********:~$ host dl.google.com 1.1.1.1 Using domain server: Name: 1.1.1.1 Address: 1.1.1.1#53 Aliases: dl.google.com has address 142.251.33.14 dl.google.com has IPv6 address 2607:f8b0:4000:806::200e skquinn@********:~$ date -u Sat 05 Mar 2022 06:25:53 AM UTC As of this writing I prefer to use Quad 9 (9.9.9.9) over the others for various reasons. I would say deliberate third-party interference can't be ruled out conclusively yet, but neither can simple hardware glitches triggered by certain sequences of bits/bytes, which include the IP address. -- Shawn K. Quinn <skquinn@rushpost.com> http://www.rantroulette.com http://www.skqrecordquest.com