I did a very careful new installation and had the same problem. So I figured that it was just me and I was giving up on getting it to work. But I'm now at least happy to hear that the problem can be duplicated. I'd still like to pursue this.
opkg uses a wget-like tool for the actual data transfer.
Just wondering, if you are you using the default OpenWrt-specific "uclient-fetch" as wget replacement, of if you have installed the proper "wget" to your system.
uclient-fetch succeeds both with and without a certificate check, but requires "https://" to be specified. With the plain filename, it fails, possibly because OpenWrt download server redirects it to https?
Maybe it mis-reacts to http-->https forwarding by server?
root@router1:~# uclient-fetch downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz
Downloading 'downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz'
Failed to allocate uclient context
root@router1:~# uclient-fetch https://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz
Downloading 'https://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz'
Connecting to 2a01:4f8:251:321::2:443
Writing to 'Packages.gz'
Packages.gz 100% |*******************************| 90113 0:00:00 ETA
Download completed (90113 bytes)
root@router1:~# uclient-fetch --no-check-certificate https://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz
Downloading 'https://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz'
Connecting to 2a01:4f8:251:321::2:443
Writing to 'Packages.gz'
Packages.gz 100% |*******************************| 90113 0:00:00 ETA
Download completed (90113 bytes)
Other option might be faulty IPv6 config, which uclient-fetch fails with.
Uclient-fetch has had problems with IPv6 addressing being present but without actual IPv6 connectivity. Full wget falls back to ipv4, but uclient-fetch fails in that (at least sometimes)
root@router1:~# ping -6 ipv6.google.com
PING ipv6.google.com (2a00:1450:4026:804::200e): 56 data bytes
64 bytes from 2a00:1450:4026:804::200e: seq=0 ttl=61 time=1.558 ms
64 bytes from 2a00:1450:4026:804::200e: seq=1 ttl=61 time=1.642 ms
^C
--- ipv6.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.558/1.600/1.642 ms
(The trouble for uclient-fetch has earlier surfaced when there is IPv6 DNS resolution, but not real connectivity. The errors have been different than yours, but that is still a possibility for controbuting to your errors)
root@router:~# ping -6 ipv6.google.com
PING ipv6.google.com (::): 56 data bytes
64 bytes from ::1: seq=0 ttl=64 time=0.191 ms
64 bytes from ::1: seq=1 ttl=64 time=0.228 ms
64 bytes from ::1: seq=2 ttl=64 time=0.160 ms
64 bytes from ::1: seq=3 ttl=64 time=0.153 ms
^C
The address resolution looks empty, and the ping answer comes in 0.2 milliseconds. Definitely not from Google, but from a local cache, proxy, Adblock, pihole, whatever.
Something blocks your real internet connectivity...
Man in the middle malware? (If you claim that there should be nothing between this and the real internet...)
@hnyman I have been trying for 3 days base install no firewall, pihole etc and still no luck. Wondering has anyone tried to install the prior version to see if that works or the new CA certificates are not working?