Package list bootstrapping issue with downloads.openwrt.org and OpenWRT default image Re: Cannot download packages in 18.06.7

[amalgamy]

Duplicate for future reference, see comment at original issue

Package Bootstrapping Issue:

Perhaps a documentation update is needed to add the steps for manually enabling TLS wget support in the packages user guide?

The nginx frontend for downloads.openwrt.org sends clients a redirect for HTTP --> HTTP upgrade, which breaks the default wget in OpenWRT images, since TLS support is not bundled in the default images. This server behavior protects against MitM HTTP attacks, but also blocks package downloads on a default OpenWRT installation.

This prevents my default (official image) installation from downloading packages - neither by command line 'opkg update' nor by luci interface (since both use the default wget package).

Attempts to download package lists will fail with the a mystery error with the default distfeeds.conf , but the underlying errors are visible by changing the URL scheme from http to https (which duplicates the effect of the HTTP Location redirect when my router connects)

wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages.

Problem verified with an official OpenWRT 18.06.7 image downloaded today: OpenWrt 18.06.7 r7976-ca47026b7d / LuCI openwrt-18.06 branch (git-20.029.49294-41e2258)

Testing with curl shows the 301 redirect for base package URL download - same forced redirect happens for wget on my router:

== Info: Connected to downloads.openwrt.org (176.9.48.73) port 80 (#0) => Send header, 182 bytes (0xb6) 0000: GET /releases/18.06.7/packages/mips_24kc/base HTTP/1.1 0038: Host: downloads.openwrt.org 0055: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100 0095: 101 Firefox/69.0 00a7: Accept: / <= Recv header, 32 bytes (0x20) 0000: HTTP/1.1 301 Moved Permanently <= Recv header, 22 bytes (0x16) 0000: Server: nginx/1.10.3 ... <= Recv header, 82 bytes (0x52) 0000: Location: http://downloads.openwrt.org/releases/18.06.7/packages 0040: /mips_24kc/base/

Note: I'm aware of these previous bug reports:

• https://bugs.openwrt.org/index.php?do=details&task_id=68&string=wget+SSL+support+not+available&advancedsearch=on&search_in_comments=1&search_in_details=1&search_for_all=1&type%5B0%5D=1&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
• https://github.com/openwrt/luci/issues/2440
• https://github.com/openwrt/luci/issues/2453
• https://github.com/openwrt/packages/issues/7907

[jow-]

1) downloads.openwrt.org does not SSL redirect:

jow@j7:~$ curl -v http://downloads.openwrt.org/releases/18.06.7/packages/x86_64/base/Packages | head -n 10
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 176.9.48.73:80...
* TCP_NODELAY set
* Connected to downloads.openwrt.org (176.9.48.73) port 80 (#0)
> GET /releases/18.06.7/packages/x86_64/base/Packages HTTP/1.1
> Host: downloads.openwrt.org
> User-Agent: curl/7.67.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.10.3
< Date: Thu, 20 Feb 2020 18:41:48 GMT
< Content-Type: text/plain
< Content-Length: 191873
< Last-Modified: Wed, 19 Feb 2020 17:57:48 GMT
< Connection: keep-alive
< ETag: "5e4d771c-2ed81"
< Access-Control-Allow-Methods: GET, POST, OPTIONS
< Access-Control-Allow-Headers: DNT, X-CustomHeader, Keep-Alive, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type, Content-Range, Range
< Accept-Ranges: bytes
< 
{ [2439 bytes data]
Package: 6in4
Version: 25-1
Depends: libc, kmod-sit, uclient-fetch
License: GPL-2.0
Section: net
Architecture: all
Installed-Size: 1521
Filename: 6in4_25-1_all.ipk
Size: 2316

2) Not LuCI related.

[amalgamy]

Confirming close:

• DNS error masquerading as an HTTPS problem
• Issue resolved by updating the default /etc/resolv.conf

[amalgamy]

My mistake - the redirections are the same URL scheme.

And again, this was a DNS error masquerading as an HTTPS problem - default /etc/resolv.conf only referenced localhost, and dnsmasq was not running yet.

Package installation problem resolved with editing /etc/resolv.conf (also manually installed openssl package dependencies via browser manual download and scp copy to router).