Opkg --no-check-certificate update doesn't work

Good Evening

i just did a fresh install and got the same results unable to update.

root@OpenWrt:~# opkg -V=4 --no-check-certificate update
Collected errors:
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz, wget returned 8.
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.1/packages/aarch64_cortex-a72/base/Packages.gz, wget returned 8.
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.1/packages/aarch64_cortex-a72/luci/Packages.gz, wget returned 8.
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.1/packages/aarch64_cortex-a72/packages/Packages.gz, wget returned 8.
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.1/packages/aarch64_cortex-a72/routing/Packages.gz, wget returned 8.
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.1/packages/aarch64_cortex-a72/telephony/Packages.gz, wget returned 8.

Did your fresh re-install work?

Similar problem:

@F5BJR I have tried this but now am recieving "Failed to decode signature", CA is installed but still does not work. or I get return 5

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.

1 Like

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.

cc @jow

Interesting, I tested with my router, and uclient-fetch fails with --no-check-certificate, while the full GNU wget succeeds.

(openssl as the SSL backend.)

root@router1:~# wget -V
GNU Wget 1.21.2 built on linux-gnu.
...

root@router1:~# wget  --no-check-certificate   downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz
--2021-11-17 18:09:18--  http://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages.gz
Resolving downloads.openwrt.org... 2a01:4f8:251:321::2, 168.119.138.211
Connecting to downloads.openwrt.org|2a01:4f8:251:321::2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90113 (88K) [application/octet-stream]
Saving to: 'Packages.gz'

Packages.gz                            100%[=========================================================================>]  88.00K  --.-KB/s    in 0.07s

2021-11-17 18:09:19 (1.29 MB/s) - 'Packages.gz' saved [90113/90113]
root@router1:~# uclient-fetch  --no-check-certificate   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

EDIT:

actually, the uclient-fetch seems to fail the whole download, even without --no-check-certificate (EDIT2: https missing from URL):

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
1 Like

hmmm.
Previous message partially wrong.

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)
1 Like

for me:

root@router:~# uclient-fetch  downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages
Downloading 'downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages'
Failed to allocate uclient context
root@router:~#

root@router:~# uclient-fetch  https://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages
Downloading 'https://downloads.openwrt.org/releases/21.02.1/targets/bcm27xx/bcm2711/packages/Packages'
Connecting to :::443
Connection error: Invalid SSL certificate
root@router:~#

root@router:~# 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 :::443
HTTP error 404
root@router:~#
1 Like

Do you have a http/https proxy?

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)

I have no proxy.
I don't have the other wget.
I can ping downloads.openwrt.org
How do I check about ipv6?

Starts with the simplest:

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...)

Ahhh... pihole is running. I'll disable that and try again!

Pihole had a regex rule that blacklisted ipv6 addresses.
opkg update now works!!!
Thank you

1 Like

Well, we spent three days battling your own extra firewall/adblock/whatever... :frowning:

When debugging something, it pays off to keep things simple (at least for the debug test duration).

@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?

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.