OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Rainer Finke - 11.11.2019

FS#2591 - Internet drop out on LAN wget YouTube on Fritz!Box 4040

Recently I’ve upgraded from a Buffalo WZR-HP-AG300H to a Fritz!Box 4040. My download speed doubled on my 400Mbit cable connection but since then I do experience as well a lot of instabilities where my previous setup was 100% stable. The OpenWrt router runs behind a DS-lite cable router (Fritz!Box 6591).

Just by watching a YouTube video (e.g. music) or by downloading with wget some files (e.g. Linux Iso images) via the LAN interface, OpenWrt on the Fritz!Box 4040 will randomly drop the internet connection completely. It disconnects the router, no ping with IPv4 or IPv6 is possible then anymore from my machine. Strangely I can access the web interface only via Wifi to reboot the router. The lost connection doesn’t come back after some time, the router requires a reboot.

If I avoid YouTube/wget, the OpenWrt router runs quite well when just doing normal internet browsing and running a web server behind the OpenWrt router.

In the log files I do not see any special hint what might cause the drop outs. I’ve tested multiple different setups already, ordered a second Fritz!Box 4040 to exclude a hardware issue, tested with 2 different cable routers, did a factory reset, flashed the latest OpenWrt snapshot (plus added luci) and used the standard configs, nothing seems to help. I assume that it is related somehow to IPv6. There are other users with the Fritz!Box 4040 that do not experience these issues, but they use it only with IPv4. As I have DS-lite, I need to use IPv6 to avoid the 6to4 tunneling on the cable router.

- Fritz!Box 4040
- OpenWrt 18.06.4 + Dev Snapshot 2019-11-10
- IPv4 and IPv6 incl. Prefix delegation to LAN interface
- Watch YouTube videos or download files with wget

For reference, I did a post on the forum:

Rainer Finke commented on 16.11.2019 09:54

After the Upgrade from OpenWrt 18.06.4 to 19.07.0-rc1 I still have the same issues.

Rainer Finke commented on 01.01.2020 14:44

After the Upgrade to OpenWrt 19.07.0-rc2 I still have the same issues.

Here is a link to a YouTube video that brings down reliable my lan connections (tested with a Linux and Windows client) within seconds or max. some minutes:

Rainer Finke commented on 04.01.2020 14:07

Out of curiosity, I bought now a Linksys EA8300 that has a Qualcomm IPQ4019 instead of the IPQ2018. After flashing OpenWrt I only made sure that the new router got as well the IPv6-PD prefix delegated to the WAN6 interface and that the LAN interface got it's IPv6 address too.

But when playing the mentioned YouTube video, the Linksys OpenWrt router sadly went down very fast, no difference! The internet connection via a pc connected with a lan cable and IPv6 was broken as before. After doing many tests, I assume YouTube (or googlevideo) must open the socket via IPv6 (verified in Firefox in about:networking), only then the internet connection will go down.

I assume that this is a IPQ40xx diver issue or OpenWrt doesn't do IPV6 reliable.

If possible, please replace in the bug report title "Fritz!Box 4040" with "IPQ40xx".

Bill commented on 22.01.2020 04:31

fwiw, same problem with EA6350 with IPv6 reported here
FS 2741

Rainer Finke commented on 22.01.2020 17:06

I did a lot of testing now with Fritz!Box 4040 and as well with Linksys EA8300 and since OpenWrt 19.07 I do run less frequent into these total network dropouts, but the issue is still there and should get addressed somehow.

Rainer Finke commented on 15.03.2020 11:38

Still an issue in 19.07.2, IPv6 and YouTube is a bad combination...

Rainer Finke commented on 16.04.2020 08:47

I had several drop outs as well with git clone and during a download from mega. Maybe I should add to my desktop a WiFi card and stop using LAN if nobody can help with this OpenWrt instability.

Rainer Finke commented on 25.04.2020 10:42

As I get more and more drop outs that require to hard reset my OpenWrt router, I assume that now Steam enabled IPv6 TCP traffic too. No downloading games brings down OpenWrt reliable as well.

When these drop outs happen on LAN, the switch doesn't work anymore. If I run an arp-scan, the router is not even visible anymore:
sudo arp-scan
Interface: enp39s0, type: EN10MB, MAC: :::::, IPv4:
Starting arp-scan 1.9.7 with 256 hosts ( ::::: (Unknown: locally administered) ::::: (Unknown: locally administered)

It seems that OpenWrt struggles with manage it's consumption of RAM. It can easily go below 10% of total available memory. But sadly, OpenWrt doesn't indicate any issue in the Processes page.

I've enabled Software Flow Offloading in the Firewall settings and it seems to help, as sometimes when the crash happened it now comes back one or two times at least, but still crashes do sadly happen nevertheless way too often.

I'm starting to wonder if dnsmasq might create these instabilities with IPv6, as I see a lot of entries in the logs before the router goes down.
Sat Apr 25 12:16:47 2020 dnsmasq-dhcp[2087]: DHCPOFFER(wlan1) ::::: Sat Apr 25 12:16:47 2020 dnsmasq-dhcp[2087]: DHCPDISCOVER(wlan1) ::::: Sat Apr 25 12:16:47 2020 dnsmasq-dhcp[2087]: DHCPOFFER(wlan1) ::::: Sat Apr 25 12:16:47 2020 dnsmasq-dhcp[2087]: DHCPDISCOVER(wlan1) ::::: Sat Apr 25 12:16:47 2020 dnsmasq-dhcp[2087]: DHCPOFFER(wlan1) ::::: Sat Apr 25 12:16:47 2020 dnsmasq-dhcp[2087]: DHCPDISCOVER(wlan1) :::::

Are 256MB of RAM too less for a fast cable connection?

Rainer Finke commented on 25.04.2020 13:33

Since Software Flow Offloading is active, the usual situation where OpenWrt crashed, can now result in a recovery of almost normal operation. This is visible in the uptime, in total 2 hours, but somehow all interfaces have been reset without interaction and they just have now an uptime of 4 minutes:

Total Uptime 0h 2m 58s
Interface Uptime: 0h 4m 30s

After the reset of the interfaces, the RAM usage is very low again... at least for some minutes (until e.g. Steam download fully recover it's operation).

Michael Lipp commented on 13.05.2020 15:57

(I'm experiencing the same problem with minor differences –

Interesting. Enabling Software Flow Offloading allows me to reliably hangup my box by executing the UM speedtest (I have 500MB/s download). As this feature is marked as experimental, I just turned it off again without giving much notice to it.

With the feature turned off, the speedtest hasn't caused a hangup yet.

Rainer Finke commented on 14.05.2020 09:06

As I've been sick and tired of the instabilities of OpenWrt on two Fritz!Box 4040 and the Linksys EA8300, I thought a give the ZyXEL NBG6817 a try and wow this thing just works stable as I was used to from the old Buffalo WZR-HP-AG300H. I can only assume that this issue might be related to the amount of RAM. The unstable devices had just 265 MB and I could get them down easily by just watching a YouTube video, downloading somehting with wget, git or Steam. The ZyXEL has 512 MB and I think this is the reason why it is so stable (but as it has another chipset, it might be related as well). The old Buffalo router was stable from my point of view because it could not download more than 25 MB/s with its weak CPU.
I wasted a lot of time, money and nerves, finally the ZyXEL is the solution for me and I can say after 2 weeks uptime that it is worth every penny.

Michael Lipp commented on 16.05.2020 13:56

Okay, I've ordered my ZyXEL NBG6817. But in the meantime I remain curious (and to be honest, I'm not really happy about having to pay three times the price for an ugly looking router because of some software bug, so at least I want to document what I've found).

It seems to me that that someone has provided a fix for a bug that looks suspiciously like the one we're discussing here: .

Pity enough, he made the mistake of combining the fix with some other contributions, got into a discussion about authorship, intended eventually to split things up again and that's where the trace is lost (

I've compiled the 19.07.2 source and the patch is not included. I'm not sure if the patch is a perfect solution. From the descriptions, it doesn't seem to fix the root cause, but rather detects the problem and cleans things up. But I'm not the expert here, it may be the only possible solution.

Regrettably, although following the build instruction, my generated sysupgrade.bin has a different size than the one distributed. So I'm hesitant to add the patch and flash the the generated sysupgrade.

"@blogic" ( seems to be the responsible author, but I have no idea how to make him aware of this bug report (it's a pity that openwrt doesn't use GitHub issues, else he'd get notified about being mentioned here).

Rainer Finke commented on 20.05.2020 09:56

I totally agree with you. It seems it is impossible to get support here on the bug tracker. But as I do not trust any proprietary software router for my network, I wanted to get OpenWrt working as I was used to. So the high costs are unfortunate, but at least I was able to find a stable solution by myself.


Available keyboard shortcuts


Task Details

Task Editing