Fritz!Box 4040 drops out internet connection if watching Youtube from LAN

Recently I've upgraded from a Buffalo WZR-HP-AG300H to a Fritz!Box 4040 and my download speed increased almost 50% on my 400Mbit cable connection, which is great. I've configured my new OpenWrt 18.06.4 setup mostly identical to the old one, but with the Fritz!Box 4040 I do experience a lot of instabilities. The OpenWrt router runs behind a cable router.

I've invested already a lot of time why the new router drops out my internet connection when just watching Youtube videos from LAN. To make it clear I do not experience this issue with WIFI, only on LAN.

So when watching videos e.g. on Youtube via LAN after some time (usually within minutes or less than an hour), my internet drops out completely. I cannot ping the OpenWrt router anymore on 192.168.1.1 or any other server on the internet like 1.1.1.1. From the internet to my OpenWrt router or to machines on my home network a ping is as well not possible anymore. A ping to my other machines on my home network continues to work fine. The only option at this point is to restart the OpenWrt router to get back internet connection (waiting some time or restarting the LAN/WAN interfaces is not enough).

I still can restart the OpenWRT router from WIFI via the LUCI web interface, somehow I can still access this via WIFI but not via LAN.

As I didn't find a similar issue when seaching this forum or on the internet I did order a new Fritz!Box 4040 to exclude hardware failure as a cause. But the new Fritz!Box 4040 shows the identical issue like the old one.

Reading the logs didn't tell me any hint what could be wrong my OpenWRT setup. As my old Buffalo router did run extremely stable for years, I can only assume it must be releated to the Fritz!Box OpenWrt image or to a special configuration.

Is somebody experience the same issues with OpenWrt?

My settings:
Fritz!Box 4040 with OpenWrt 18.06.4 behind cable router (DS-lite)
eth1 - WAN+WAN6
eth0 - LAN
wlan0+wlan1 - bridge WIFI
wlan0 - guest WIFI
stubby for DNS over https
luci-ssl-openssl for https web interface
Firewall adjusted for my home network into 3 zones (LAN, WIFI, GUEST)
Some machines on my home network got a fixed IP assigned by OpenWrt

1 Like

Might be switch-config related with a guest VLAN involved and an IPQ4018. Did you touch VLAN 1 or 2 in any way?

Thanks for your answer, jeff!

I've tried the default settings in switch with "Enable VLAN functionality" on and just the VLAN id 1. After reading that this is an issue with the Fritz!Box 4040, I've disabled VLAN in the switch settings, but it didn't help. At least for my 4 LAN ports I didn't try to use anything related to VLAN.

But this makes me wonder if maybe my settings to split LAN, WLAN and GUEST into own zones in the firewall might create something similar like a VLAN? Usually the LAN is a bride combined with WLAN0 and WLAN1.

The firewall zones are independent of VLAN implementation, though they often reference VLAN sub-interfaces.

I know the ipq40xx devices require careful handling of VLAN configuration and am not confident that LuCI performs it correctly. VLAN interfaces are generally needed for guest network implementation.

I would copy your current /etc/config/network for reference, delete the original, then reboot to create a fresh, default copy. Then I would configure the guest network sub-interface and, if needed, switch VLAN, manually, not using LuCI. Don’t use VLAN 1 or 2 when you do, but a higher-numbered one.

1 Like

More details about the VLAN/switch issue with the FB4040 can be found here:

I'm running the FB4040 without having touched the VLAN/switch config and do not have such issues as you have described here. (on german cable 400 MBit)
Maybe a reset to (openwrt-)defaults and reconfiguring the FB4040 without touching the VLAN/switch via LuCI might help ?

Cheers,
Thomas

I tried to not touch the VLAN/switch settings, did a factory reset more than 2 times. After removing the /etc/config/network, the following was created automatically:

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'auto'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option ifname 'eth1'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0'

So the config I've created before in interfaces doesn't look to bad, from my point of view:

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdea:0f76:d196::/48'

config interface 'lan'
        option ifname 'eth0'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '64'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'
        option peerdns '0'
        option dns '127.0.0.1'

config interface 'wan6'
        option ifname 'eth1'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix '64'
        option peerdns '0'
        option dns '0::1'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0'

config interface 'WIFI'
        option proto 'static'
        option ipaddr '192.168.2.1'
        option netmask '255.255.255.0'
        option type 'bridge'
        option ip6assign '64'

config interface 'EXTERN'
        option proto 'static'
        option ipaddr '192.168.3.1'
        option netmask '255.255.255.0'
        option ip6assign '64'

But I noticed one difference, I got rid of the bridge for LAN (thought it is not required). I did enable this bridge now again for LAN with just one interface eth0. And I did the same now for EXTERN with wlan0-1. So time for another test round...

Thanks jeff and tomtom Could one of you please post your switch and switch_vlan interface/network settings for reference?

I don't know if netifd will auto-associate a wireless interface with something that isn't a bridge (EXTERN). Relying on the name being wlan0-1 is, in my experience, not robust. The output of

brctl show

should show that the wireless is associated with the bridge. Working with the "raw" wireless interface is likely possible with manual configuration, but may not be straightforward with LuCI, both as far as managing the interface goes, as well as associating it with firewall zones.

(As a matter of personal style, I use lower-case interface names. It is LuCI that, I believe, capitalizes them.)

Checking that the firewall zones associated with WIFI and EXTERN allow forwarding to WAN would be a good step to take.

(My config isn't going to be very helpful as I run a different IPQ4109-based device as a "dumb AP" -- no forwarding, only bridging).

Did some tests, but adding a bridge to each interface lan and EXTERN didn't help, Youtube dropped out my router as before after some time (20 min, reboot and then 3 min)

brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.f0b0147c80a1       no              eth0
br-WIFI         7fff.f0b0147c80a3       no              wlan0
br-EXTERN       7fff.f2b0147c80a3       no              wlan0-1

Looks ok to me, firewall zones are correctly assigned and seem to work fine too for my wireless networks (at least until the drop out).
I assume I could try to follow your naming convention and I could name my firewall zones identically to the interfaces, but I do not believe this will change something.

As I have currently 2 routers around, I made the observation, that my router will drop out only when there are multiple devices connected, and I play Youtube videos via lan. If there is no device attached except the machine playing videos via lan, I couldn't reproduce the issue.

Multiple routers - no double NAT or the like?

It’s sounding like it may be an ARP-table problem or something route-related. If you have multiple, interconnected switches, I’d enable STP on all of them. Past that, I would start looking at ARP tables and packets and their flow at the various nodes.

I do have the Fritz!Box 2 times now, both are connected directly to the DS-lite cable router. On one Fritz!Box my complete home network is attached, there I can reproduce the internet drop out if playing Youtube videos via lan. On the second one I just have a single machine attached and I cannot reproduce the issue.

As I do not have full control over the cable router, I might end of with double NAT for IPv4 connections, they didn't cause an issue in the past. But I will look at the config.

If you're a customer of "Unitymedia" you can check your connection type
after logging in their customer portal, mine is IPv4, which allows me to
operate the "connect box" in bridge mode. (modem only, no routing)
If your connection type is DS-Lite then you surely do double NAT.

Here is my /etc/config/network for reference:

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd44:c606:9f0f::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0'
	option proto 'static'
	option ipaddr '192.168.0.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option delegate '0'

config interface 'wan'
	option ifname 'eth1'
	option proto 'dhcp'

config interface 'wan6'
	option ifname 'eth1'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 0'

config interface 'guest'
	option proto 'static'
	option ipaddr '192.168.66.1'
	option netmask '255.255.255.0'
	option delegate '0'

And this the output of "brctl show"

bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.f0b014540bd3       no              eth0
                                                        wlan1
                                                        wlan0

Hope that helps.

Cheers,
Thomas

I do have a DS-lite connection from Unitymedia with an extremely limited connect box router (firewall is off). I've delegated an IPv6 prefix to my OpenWrt router. This worked fine for years with the Buffalo router. After a lot of testing I still see no root cause why the Fritz!Box 4040 drops internet by just playing some Youtube videos via lan. I've removed now the interfaces for WIFI and EXTERN so there is now just one bridge with lan and the 2 wireless networks (both disabled for now), maybe that reduces the risks of an routing issue of IPv6. At this moment I believe it is not related to IPv4, as my second Fritz!Box doesn't get an IPv6 prefix delegated (PD) and that might be the reason why it seems to work more stable. But might be just coincidence, will run more tests.

Short update. I've tried now an openwrt development snapshort and it dropped as well the internet connection after 40 min playing a music youtube video. Even when testing multiple different configurations I was not able to find any cause for this issue. I assume that this might be a driver issue. But I have no clue how to verify this.

When downloading a bigger file with wget I get these internet drop outs as well. I just had to download in the last days several times an Arch Linux iso image and in many of these downloads the internet and connection to the router stopped completely again.

Last week the Unitymedia Connect Box got replaced with the new Docsis 3.1 Vodafone Station. This thing is a total disaster, it didn't allow prefix delegation and disallow the firewall is only possible for 24h only. So my complete network was not usable anymore and I had to replace this thing with a own Fritz!Box 6591. The setup was a little complicated for IPv6, prefix delegation and an exposed host, but at least now my complete network works again.

But sadly, even with this new Fritz!Box 6591 the situation is still the same... OpenWrt on the Fritz!Box 4040 is still creating the same internet drop outs!

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: https://www.youtube.com/watch?v=y7e-GC6oGhg

From my bug report https://bugs.openwrt.org/index.php?do=details&task_id=2591:

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, only then the internet connection will go down.

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

Since upgrading to OpenWrt 19.07 my network seems stable without any drop outs so far. I have to further test this, but I do hope that this is solved now.

I did a lot of testing and the problem is still there, OpenWrt 19.07 is more stable, but there are still complete drop outs :frowning:

Does the problem go away if you delete the WAN6 interface?
(ie. do not use IPv6)

I do not have to delete the WAN6 interface, it is enough to make sure that the desktop with a lan connection is using "IPv4 only" to avoid this issue. I do see this issue only when IPv6 is enabled or with "IPv6 only", but as I use DS-lite disabling IPv4 is not an option.

But I understand most users will use IPv4 without manually making sure IPv6 works fine and therefore are mostly not affected by this bug.