dietpi-update fails (as does apt-get update) on Pine64, with "Connection failed" unexpectedly about dietpi

[carstenraddatz]

The MTU of 1360 was found by the built-in tool earlier, about 15 months ago. Now I followed the MTU hunch doing a repetive ping -4 -f github.com -M do -c4 -i1 -s <value>, and any packetsize higher than 1290 brought errors for me, what gives. (Jumped down from 1360 in increments of 20, not 1 as dietpi-optimal_mtu tool does, this was quick.)

To make it survive a reboot I put it into /etc/dhcp/dhclient.conf near the top:

interface "eth0" {
default interface-mtu 1290;
supersede interface-mtu 1290;
}

This is getting ut of scope, my Pine64 has that wifi card installed. Downloading anything using the wlan0 interface works without a fuss. Just change the metric in routing, dietpi-updates runs successfully.

Now I have two ways of solving the original issue. Thank you for your time.

[Joulinar]

I see all of them are http connections. Maybe they got blocked somewhere. You could try to switch to https instead

[carstenraddatz]

Good catch! I changed the connections to https, now I'm getting 11: Resource temporarily unavailable. Will change the mirrors for Armbian, it seems a problem there.

[carstenraddatz]

That fixed the issue. Not a DietPi problem at all, sorry for the noise. (Took a few runs until an Armbian mirror was picked that did deliver the stuff needed.)

[Joulinar]

It's not the first time an Armbian apt mirror has been a little fussy. Good you solved it.

[MichaIng]

Good to know that ftp.de.debian.org finally supports HTTPS as well. Not sure why it actually failed with plain HTTP, but HTTPS is better anyway.

... although, it does not work in my case 🤔:

Err:1 https://ftp.de.debian.org/debian trixie InRelease
  Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected.  Could not handshake: Error in the certificate verification. [IP: 141.76.2.4 443]
Fetched 23.6 kB in 8s (2963 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch https://ftp.de.debian.org/debian/dists/trixie/InRelease  Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected.  Could not handshake: Error in the certificate verification. [IP: 141.76.2.4 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.

@carstenraddatz you really use https://ftp.de.debian.org now and it does not throw this TLS certificate warning?

With plain HTTP it works fine here:

Get:1 http://ftp.de.debian.org/debian trixie InRelease [157 kB]
Hit:2 https://archive.raspberrypi.com/debian bookworm InRelease
Get:3 http://ftp.de.debian.org/debian trixie/main armhf Packages [8762 kB]
Fetched 8919 kB in 9s (960 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.

Confusing.

And regarding Armbian. Did you use http:// or https:// in your /etc/apt/souces.list.d/*armbian.list? We actually changed it to HTTPS during DietPi v8.11 update ... ah, I see a problem there: We did this for armbian.list, but later, we added a pre-patch to rename it to dietpi-armbian.list. So the patch for HTTPS does not work anymore. I'll fix this. Hence an issue our end, not one with Armbian.
EDIT2: Ah nope, we apply the change to both files. Hence not sure why in your case it still seems to use plain HTTP. Can you check that:

cat /etc/apt/sources.list.d/*armbian.list

[carstenraddatz]

So help clear things up, as pasted, my log there showed no TLS certificate warning. But see the Get:1/Err:1 pair, it shows a timeout error for ftp.de.debian.org, nothing certificate related. (In many attempts I did get the unspecific "Connection failed" result, too, again nothing TLS related.) But you knew that.

TBH, I don't even recall where I changed http to https in my attempts. At the moment I have

$ sudo cat /etc/apt/sources.list.d/*armbian.list
deb https://apt.armbian.com/ bullseye main

On update attempts I'm getting a curl: (56) OpenSSL SSL_read: Connection timed out, errno 110:

│ Downloading update archive │
│ - Command: curl -sSfLO https://github.com/MichaIng/DietPi/archive/master.tar.gz │
│ - Exit code: 56

Might this be an MTU issue after all? The file downloads normally on any other machine I tried, on cable ISP or not.

FWIW The DietPi-Config dialogue itself offers to set https://ftp.debian.org/debian as the "Global" mirror. The upstream certificate policy apparently does not trickle down nicely (:

[MichaIng]

Ah, I thought you fixed the ftp.de.debian.org issue by switching to HTTPS as well. Makes sense that this does not work: each domain and subdomain requires an own certificate or SAN entry in another certificate. The regional Debian repo mirrors are operated by other institutions which have their own domain names/hostnames for which their certificate is valid. They would need to add ftp.xy.debian.org as SAN entry to their certificate to make this valid. E.g. ftp.de.debian.org ships a certificate which is valid only for debian.inf.tu-dresden.de, the actual hostname of this server. The Debian domain is just pointing to the same server to give this a more official look in the mirror list, as trusted by Debian, or so. What hence does work is using https://debian.inf.tu-dresden.de/debian/ with HTTPS. But it is possible that regional Debian mirrors change in the future.

Not sure why you still had http:// in your armbian.list, but it should work both anyway. Indeed seems more like general network issue. I don't really know in which circumstances the MTU may be an issue. But we actually have an old tool to find the largest possible one, starting with 1500:

dietpi-optimal_mtu

which tests against dietpi.com, or

dietpi-optimal_mtu github.com

Then it can be applied via:

ip link set dev eth0 mtu <size>

assuming eth0 to be the Internet facing interface.

[MichaIng]

Okay great. /etc/dhcp/dhclient.conf seems to be a common method to set this permanently when DHCP is used. Another way is using mtu 1290 in /etc/network/interfaces. respectively /etc/network/interfaces.d.