You could also disable the odhcpd service that takes care of the IPv6 assignments on LAN.
Ps. I have never really tried to disable IPv6, as I have been eagerly using the IPv6 since etc. since 2010, already well before I had proper IPv6 connectivity from ISP. So, my practical knowledge about really disabling it is negligible.
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. 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.
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.
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.
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.
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)?
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.