opkg / uclient-fetch: Doesn't fall back to IPv4 when IPv6 connectivity is bad

[KA2107]

Describe the bug

opkg doesn't fallback to IPv4 for downloading when IPv6 connectivity is bad. Looks like IPv4 / IPv6 Happy Eyeballs (https://datatracker.ietf.org/doc/html/rfc8305) is not implemented in opkg or the downloader tool / library it uses.

ISP: Ting Fiber in North Carolina, U.S.A.

opkg version d038e5b6d155784575f62a66a8bb7e874173e92e (2022-02-24)

OpenWrt version

r27350-c4a9265160

OpenWrt release

SNAPSHOT

OpenWrt target/subtarget

qualcommax/ipq807x

Device

Dynalink DL-WRX36

Image kind

Official downloaded image

Steps to reproduce

No response

Actual behaviour

# opkg update
Downloading https://downloads.openwrt.org/snapshots/targets/qualcommax/ipq807x/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading https://downloads.openwrt.org/snapshots/targets/qualcommax/ipq807x/packages/Packages.sig
^C

# ping -6 downloads.openwrt.org
PING downloads.openwrt.org (2a04:4e42::644) 56 data bytes
From 2606:8e80:1810:0:1::b55 icmp_seq=1 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=2 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=3 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=4 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=5 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=6 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=7 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=8 Destination unreachable: Address unreachable
From 2606:8e80:1810:0:1::b55 icmp_seq=9 Destination unreachable: Address unreachable
64 bytes from 2a04:4e42::644: icmp_seq=10 ttl=58 time=271 ms
64 bytes from 2a04:4e42::644: icmp_seq=11 ttl=58 time=9.49 ms
64 bytes from 2a04:4e42::644: icmp_seq=12 ttl=58 time=9.77 ms
64 bytes from 2a04:4e42::644: icmp_seq=13 ttl=58 time=9.05 ms
64 bytes from 2a04:4e42::644: icmp_seq=14 ttl=58 time=10.2 ms
64 bytes from 2a04:4e42::644: icmp_seq=15 ttl=58 time=9.29 ms
64 bytes from 2a04:4e42::644: icmp_seq=16 ttl=58 time=8.94 ms
64 bytes from 2a04:4e42::644: icmp_seq=17 ttl=58 time=9.04 ms
^C
--- downloads.openwrt.org ping statistics ---
17 packets transmitted, 8 received, +9 errors, 52.9412% packet loss, time 16339ms
rtt min/avg/max/mdev = 8.942/42.164/271.499/86.681 ms

# ping -4 downloads.openwrt.org
PING dualstack.j.sni.global.fastly.net (151.101.130.132) 56(84) bytes of data.
64 bytes from 151.101.130.132: icmp_seq=1 ttl=58 time=7.71 ms
64 bytes from 151.101.130.132: icmp_seq=2 ttl=58 time=6.82 ms
64 bytes from 151.101.130.132: icmp_seq=3 ttl=58 time=6.78 ms
64 bytes from 151.101.130.132: icmp_seq=4 ttl=58 time=6.95 ms
64 bytes from 151.101.130.132: icmp_seq=5 ttl=58 time=6.88 ms
64 bytes from 151.101.130.132: icmp_seq=6 ttl=58 time=6.88 ms
64 bytes from 151.101.130.132: icmp_seq=7 ttl=58 time=7.24 ms
64 bytes from 151.101.130.132: icmp_seq=8 ttl=58 time=6.88 ms
64 bytes from 151.101.130.132: icmp_seq=9 ttl=58 time=6.90 ms
64 bytes from 151.101.130.132: icmp_seq=10 ttl=58 time=6.90 ms
64 bytes from 151.101.130.132: icmp_seq=11 ttl=58 time=6.87 ms
64 bytes from 151.101.130.132: icmp_seq=12 ttl=58 time=6.99 ms
64 bytes from 151.101.130.132: icmp_seq=13 ttl=58 time=6.80 ms
64 bytes from 151.101.130.132: icmp_seq=14 ttl=58 time=6.88 ms
64 bytes from 151.101.130.132: icmp_seq=15 ttl=58 time=6.87 ms
64 bytes from 151.101.130.132: icmp_seq=16 ttl=58 time=6.88 ms
64 bytes from 151.101.130.132: icmp_seq=17 ttl=58 time=6.90 ms
64 bytes from 151.101.130.132: icmp_seq=18 ttl=58 time=6.87 ms
64 bytes from 151.101.130.132: icmp_seq=19 ttl=58 time=6.89 ms
^C
--- dualstack.j.sni.global.fastly.net ping statistics ---
19 packets transmitted, 19 received, 0% packet loss, time 18032ms
rtt min/avg/max/mdev = 6.782/6.941/7.707/0.202 ms

Expected behaviour

No response

Additional info

No response

Diffconfig

No response

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.

[jow-]

This is actually a uclient-fetch bug.

[Neustradamus]

@ynezz: With your recent issue transfer from openwrt/openwrt, it is in double now with:

• uclient-fetch: Doesn't fall back to IPv4 when IPv6 connectivity is bad #7

[KA2107]

Similar issue also exists in APK (Alpine Package Keeper) that OpenWrt is planning to switch to.

https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10862