I have a small home network with about 5 connected devices all on WiFi. I'm using a RPi 4 with OpenWrt 24.10.1 as a router and WiFi access point. I seem to lose internet whenever a lot of bandwidth is used, or so I suspect. But after installing and configuring SQM according to https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm, my internet still fails perhaps once a day or every other day. Rebooting the router fixes the problem, but I'd like help with a more permanent solution.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback a brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN group default qlen 1000
link/ether b brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000
link/ether c brd ff:ff:ff:ff:ff:ff
inet public_ip brd public_ip scope global eth1
valid_lft forever preferred_lft forever
inet6 scope link proto kernel_ll
valid_lft forever preferred_lft forever
4: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
link/ether d brd ff:ff:ff:ff:ff:ff permaddr 2c:cf:67:4d:2e:ab
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e brd ff:ff:ff:ff:ff:ff
inet 192.168.5.1/22 brd 192.168.7.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fddb:4626:91c::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::2ecf:67ff:fe4d:2eaa/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
8: vpn: <POINTOPOINT,NOARP> mtu 1420 qdisc noop state DOWN group default qlen 1000
link/none
inet 192.168.9.1/24 brd 192.168.9.255 scope global vpn
valid_lft forever preferred_lft forever
inet6 fd00:9::1/64 scope global
valid_lft forever preferred_lft forever
9: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 192.168.4.13/22 brd 192.168.7.255 scope global wg0
valid_lft forever preferred_lft forever
19: ifb4eth1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc cake state UNKNOWN group default qlen 32
link/ether f brd ff:ff:ff:ff:ff:ff
inet6 fe80::60bc:d7ff:fed0:9c51/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
I didn't get any MAC addresses in the config files.
As for system logs, I'll have to wait until it happens again, since I rebooted the system last time.
Also, where do I find the log? I checked /tmp and /var, but found nothing. dmesg shows a bunch of maybe unrelated errors after attempting to reproduce the issue. I started a large download and video streams on a few hosts.
[41146.118275] brcmfmac: brcmf_sdio_read_control: last control frame is being processed.
[41146.126166] ieee80211 phy0: brcmf_cfg80211_dump_station: BRCMF_C_GET_ASSOCLIST failed, err=-512
[41149.287694] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[41149.296885] ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110
To tell you the truth I didn't have the foresight to check the other interfaces at the time. Now that I think about it though, in each case, everyone was still connected to the LAN but not the internet...
They must not overlap. As is the case for all routed interfaces -- they must all be unique and non-overlapping.
The solution is pretty easy -- set each of the networks to /24 (rather than /22). And change the phone peer to use an address on the WG subnet (i.e. 192.168.4.2/32).
That looks better, but I prefer to review the config file itself.
You already have the rule that is needed to allow the VPN to connect remotely:
Also, regarding your wireless performance... as @LilRedDog points out, the radio is "weak" but works. It is a very poor choice as an AP. It has a very limited 1x1 radio which has poor range and poor throughput. But even worse is that it is not good at handling multiple client devices because of the 1x1 radio system -- this means that the performance severely degrades as a function of using multiple clients. It will still be functional, but you will have much better performance with essentially any old purpose built wifi AP or an all-in-one device (including older devices).
Once the main interface is a /24 and the peer is on the same subnet, you specify the peer as a /32 because only traffic bound for that peer should go through the tunnel. The traffic can be from anywhere, but it the /32 is the to address.
Okay, it happened again. I grabbed both the system and kernel log. From the system log, these notices came up multiple times. They seemed suspicious to me.
Fri Jun 13 15:26:49 2025 daemon.err dnsmasq[1]: failed to send packet: Required key not available
...
Sat Jun 14 10:12:18 2025 daemon.info hostapd: phy0-ap0: STA <unknown-mac> IEEE 802.11: disassociated
...
Sat Jun 14 10:52:21 2025 daemon.warn odhcpd[1113]: No default route present, overriding ra_lifetime to 0!
