(Bad) ipv6 connexion prevents update

[pepie34]

If the ipv6 routing is not working (for example bad ipv6 gateway), the downloader of the updater does not fallback to ipv4.
The update process is then stuck forever.

Disabling ipv6 resolves the problem.

May be wget in the update script could be used with a --timeout arg and/or --prefer-family arg

[Tim Curtis]

Whats your network config where ipv4 is not available?

[pepie34]

Whats your network config where ipv4 is not available?

The ipv4 was available !

This problem happens when both ipv4 and ipv6 are available but ipv6 deffective.

wget starts on ipv6 and does not fallback to ipv4 even if ipv4 is available

[Tim Curtis]

The challenge is how to create that network config on my end so I can try to reproduce your issue.

[TheOldPresbyope]

@pepie34

I'm confused about your home network configuration.

I assume you are using the default DHCP option in your moOde network configuration.

It sounds like your home router (and access point if using WiFi LAN) is configured to support IPv6, so your moOde player has been assigned both IPv4 and IPv6 addresses.

Where/what is the "bad" IPv6 gateway or whatever it is that is preventing downloads from an IPv6 server?

Frankly, I consider this a pathological configuration and I'm not sure it's up to moOde to fix it. I'd just disable IPv6 in the router.

Yes, as far as I can tell, wget does not fallback from IPv6 to IPv4 if the IPv6 connection isn't "working". I got only a couple hits in a Web search and they weren't very enlightening.

I think it's up to you to do the experimentation of various wget options to see what works in your configuration.

Presumably, wget --inet4-only would work for you but building that into the updater script would restrict all users.

Presumably, wget --prefer-family=IPv6 would not work for you, but you could try.

Possibly, wget --connect-timeout=10 would at least timeout your wget attempt in 10 seconds (assuming I understand this option correctly) but only you can find out. It wouldn't cause a fallback, or course, but at least it wouldn't be likely to inhibit other users if this were built into the updater script.

Here at Chaos Manor (a tip of the hat to Jerry Pournelle and his old Byte Magazine column), my ISP and ISP-provided router/access point have solid IPv6 support so my players have both an IPv4 address and a full complement of IPv6 addresses.

Here's some experiments I did with one player, assuming the latest moOde update file

Code:

# first, what are the IPv4 (A) and IPv6 (AAAA) records for the update server

rho@m902pi3bp:~ $ dig raw.githubusercontent.com A

; <<>> DiG 9.18.24-1-Debian <<>> raw.githubusercontent.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11804
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;raw.githubusercontent.com.    IN    A

;; ANSWER SECTION:
raw.githubusercontent.com. 1437    IN    A    185.199.110.133
raw.githubusercontent.com. 1437    IN    A    185.199.111.133
raw.githubusercontent.com. 1437    IN    A    185.199.108.133
raw.githubusercontent.com. 1437    IN    A    185.199.109.133

;; Query time: 23 msec
;; SERVER: 75.75.75.75#53(75.75.75.75) (UDP)
;; WHEN: Sat Jun 15 11:00:13 EDT 2024
;; MSG SIZE  rcvd: 118

xxx@m902pi3bp:~ $ dig raw.githubusercontent.com AAAA

; <<>> DiG 9.18.24-1-Debian <<>> raw.githubusercontent.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33521
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;raw.githubusercontent.com.    IN    AAAA

;; ANSWER SECTION:
raw.githubusercontent.com. 2370    IN    AAAA    2606:50c0:8003::154
raw.githubusercontent.com. 2370    IN    AAAA    2606:50c0:8002::154
raw.githubusercontent.com. 2370    IN    AAAA    2606:50c0:8000::154
raw.githubusercontent.com. 2370    IN    AAAA    2606:50c0:8001::154

;; Query time: 24 msec
;; SERVER: 75.75.75.75#53(75.75.75.75) (UDP)
;; WHEN: Sat Jun 15 11:02:28 EDT 2024
;; MSG SIZE  rcvd: 166

Notice that both sets of records are returned from the DNS server via IPv4.  I could get them via the server's IPv6 address by using the -6 option.


Now, let's see what happens when I try to download the update file with no wget options

Code:

xxx@m902pi3bp:~ $ wget  https://raw.githubusercontent.com/moode-player/updates/main/moode-player/update-moode9.zip
--2024-06-15 10:37:05--  https://raw.githubusercontent.com/moode-player/updates/main/moode-player/update-moode9.zip
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.108.133, 185.199.109.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2179 (2.1K) [application/zip]
...

Interestingly, wget chose the IPv4 protocol, I suppose because the A record was delivered first when it queried DNS.

Let's try again, this time forcing IPv6

Code:

xxx@m902pi3bp:~ $ wget --inet6-only https://raw.githubusercontent.com/moode-player/updates/main/moode-player/update-moode9.zip
--2024-06-15 10:38:51--  https://raw.githubusercontent.com/moode-player/updates/main/moode-player/update-moode9.zip
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 2606:50c0:8000::154, 2606:50c0:8001::154, 2606:50c0:8002::154, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|2606:50c0:8000::154|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2179 (2.1K) [application/zip]
...

Works a treat in my situation as expected,

Now, let's tell wget to prefer IPv6 if it's available

Code:

rho@m902pi3bp:~ $ wget --prefer-family=IPv6 https://raw.githubusercontent.com/moode-player/updates/main/moode-player/update-moode9.zip
--2024-06-15 10:40:53--  https://raw.githubusercontent.com/moode-player/updates/main/moode-player/update-moode9.zip
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 2606:50c0:8002::154, 2606:50c0:8003::154, 2606:50c0:8000::154, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|2606:50c0:8002::154|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2179 (2.1K) [application/zip]
,,.

Again, works a treat in my situation as expected.

I won't bore you with the output where I used the --connect-timeout option. It amounts to a no-op here because my IPv4 and IPv6 connections are both functioning and blazingly fast.

Just my 2 cents worth.

Regards,
Kent

[pepie34]

To clarify the situation.

I have two routers, the provider router and a private router (with openwrt).
The private router is connected behind the provider router

The ipv6 was working well. I had just to give the public prefix to the router wan6 configuration.

Nevertheless, I have recently moved.
Even if the provider router is physically the same after the move its ipv6 prefix changed.
The old public prefix was still configured in my private router.

The situation was very strange. On Ip attribution for my computers, I still get a ipv6 address with an old prefix. dns was resolving in ipv6 but no working ipv6 connection.
Most programs were falling back to ipv4. So I only notice the problem after two weeks and it took me two more days to understand what was happening.

That's said the ipv6 is not the problem and effectively none of the network stack of the raspiOS should be modified.

BUT having a connection timeout on wget seems to be a good policy for whatever problem there is on the network. For this ipv6 problem or another.
The aim of my post was this.