Can't find package lists after upgrading to 19.07

No offence meant, but that example doesn't make sense to me: there's the option

option dhcpv6 'server'

which means, ipv6 is active. Isn't it?

This gets more and more bizarre. Even if I put

176.9.48.73 downloads.openwrt.org mirror-02.infra.openwrt.org

into /etc/hosts, wget is not capable of downloading anything, unless I use the option "-4" on command line.

Also putting

prefer-family = IPv4

into a file /etc/wgetrc doesn't do the job, although it should make wget use ip4, according to the manual.

For today I am fed up with trying. :frowning: I will re-flash version 18 again and I will open an official bug report for this. I do not believe that this malfunction is all my fault.

1 Like

I meant that remove those, as they are IPv6 related.

Those option have never been activated, and every network was set to disable anything that is related to ipv6.

While I am typing theses lines, opkg on 18.06.6 is downloading the package lists and reinstalling additional packages without any error.

It is jinxed. :frowning:

As a test - why not try changing domain to IPv4 address in /etc/opkg/distfeeds.conf?

sed -i 's/downloads.openwrt.org/176.9.48.73/g' /etc/opkg/distfeeds.conf && opkg update

If this works - another argument for an IPv6 issue.

Please don't feel insulted, but I don't think another test is necessary. There is a problem with ipv6, I see that now. But the big question is: what's the reason for this problem? There has to be a small, but very important difference between version 18 and 19, that causes wget not being able to download, unless the command line option "-4" is used. And that option really has to be the command line option, it is even disregarded as part of a config file.

Maybe wget has been compiled incorrect, and the use of ipv6 has been hard-coded in, without any alternative. I don't know, but it would explain why this error even occurs right after flashing, without restoring and previously backed up options. You see: that is the part that puzzles me the most. If it happened after I restored my network settings, the case would be obvious. But the error even happens on the "naked" system, without any option altered or restored.

In other words: after flashing 18 and resetting, "opkg update" works, flashing 19 and resetting "opkg update" does not work. Same situation, just two different OS versions. I would say that limits the number of suspects very much.

Does ip -family inet6 route list show any IPv6 routes?

Definitely remove the option ipv6 server and option ra server from the DHCP configuration for an IPv4 only network. But I don't think this will affect Internet access from OpenWrt itself.

Eureka!!! :slight_smile:

I found the error. Or at least I found a way to circumvent it:

Because the trouble only happened when wget was involved (see above: traceroute, ping and dns was working), I came to the idea that it might be worth it to try another version of wget, So I downloaded the package wget-nossl from the repository, then I flashed version 19, without keeping settings, and then I copied the downloaded package onto the router, installed it and -voila!- suddenly opkg could download the package lists and additional packages.

Once wget was working, I replaced it with the ssl version. I couldn't install the ssl version before, because it has too many dependencies.

Even now, after applying all the necessary networking settings and installing all the required additional packages, I can still reproduce this error: as soon as I uninstall the package wget-ssl, opkg can't download anything at all again. If I re-install the package again, opkg can download again.

I can only think of one explanation of for this: the busybox version of wget is faulty and does not work with ip4, unless given "-4" as a command line argument. :frowning:

It is probably actually the OpenWrt specific wget clone, uclient-fetch, that misbehaves. (It masquerades as the default wget.)

And it works nicely with plain IPv4, but somehow you have IPv6 addressing info but no proper connectivity, and that probably confuses it.

But why does this not happen when I flash the previous version? In OpenWRT 18 the wget clone works perfectly from the beginning.

Another point: it is just this wget clone, that misbehaves. See above: traceroute, ping and name resolving works.

And last, but not least: how can there be any ipv6 info, when I turn off ipv6 on any and each network device?

Probably somewhat better IPv6 support in 19.07 than in 18.06 (and a newer uclient-fetch version)

In your case the better IPv6 support causes trouble as you have IPv6 DNS but not connectivity.

No, I don't run a ipv6 name server. As I stated before, I turned ipv6 off completely on each network device and I never activated it in dnsmasq. Where should this ipv6 information come from?

Furthermore: if this wget clone notices it can't connect via ipv6, shouldn't it try ip4 before it exits with "can't connect" error?

AAAA records (IPv6 addresses) in addition of the A records (IPv4) as answer to normal DNS query. Like your example above shows. That is different than actual IPv6 traffic.

This must have its origin in my ISP's dns, it can't be cast by my internal dnsmasq.

But even if wget receives an ipv6 information from my ISP: before exiting completely, it should try ip4. Especially, when you tell the OS not to load any ipv6 related modules in /etc/sysctl.conf. The program should notice that ipv6 does not work, while ip4 does work. So it behaved in previous versions, why can't it do so in version 19?

It happened again: this time I was using version 19.07 with a setup from scratch, so there could be no inherited burden from version 18 or earlier.

Yesterday I upgraded to 19.07.1. And of course I used the convenience to keep my settings. That is, I suppose, what this option is offered for, and upgrading from version X.07 to X.07.1 shouldn't cause any trouble.

But again, after the reboot, the package lists could not be downloaded. I had to download the package "wget" on my working machine, upload it to the router and install it manually. After that, "opkg" was functional.

It keeps settings (=config files), but you will naturally need to re-install all add-on packages after the sysupgrade.

1 Like

But there shouldn't be the need to separately install wget after a sysupgrade for opkg to work in the first place.

@weka After installation of 19.07.0 from scratch, opkg update worked out of the box, without the need to separately install wget or use -4?

1 Like

Apparently the default wget, built-in uclient-fetch, dislikes a combination of IPv6 DNS answers without actual IPv6 connectivity.

That is my take of the above debugging.

1 Like

@tmomas: No, it didn't. I still had to install "wget" manually.

I took the chance to finally flash my FB4040 directly with 19.07.1.
Smooth installation via fritzflash.py.

After that, my first action was to update the package list. Failed, because I was dumb.
Manually installed wget + libpcre, still failed (because I still was dumb).

Once I connected the 4040 to my FB6591, package update worked.
Uninstalled the previously installed wget + libpcre -> package update still works.

I'm on unitymedia DS-lite. You too?
What's in front of your 4040, the Connectbox or a FB (if yes, which)?

My ISP's modem is IP4 only.