R7800 wifi random traffic drop

I'm using OpenWrt on a Netgear R7800 (Netgear Nighthawk X4S R7800). Now and then I get problems with Wifi on a set of my wifi devices (another set of devices never have problems).

The devices (both laptop and phone) are connected to Wifi.
Then this happens (Often several days in-between):

  • Wifi is working fine (browsing the web works)
  • A device indicates that Wifi is connected (the little "wifi connected" icon is shown in the taskbar), but trying to use a web browser, it cannot connect to any webpage.

To me it looks like the Wifi is actually OK, but packets are being dropped? Any ideas?

I have not tried any other action than browsing the web, so far. If I disconnect and then reconnect to the Wifi, there are no longer any problems.

I found these in dmesg, but the last output is 9 hours old, while the problem happened 20 minutes ago.

[1212181.087687] ath10k_pci 0001:01:00.0: Invalid peer id 292 peer stats buffer
[1302096.948240] ath10k_pci 0001:01:00.0: Invalid peer id 319 peer stats buffer
[1441309.711221] ath10k_pci 0001:01:00.0: Invalid peer id 349 peer stats buffer
root@host:~#

Model: Netgear Nighthawk X4S R7800
Firmware Version: OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152)

All devices are currently connected to 802.11n (probably since I added a -5g suffix on 802.11ac a few weeks back):
Qualcomm Atheros QCA9984 802.11nac
Channel: 36 (5.180 GHz) | Bitrate: ? Mbit/s
Qualcomm Atheros QCA9984 802.11bgn
Channel: 1 (2.412 GHz) | Bitrate: 85.2 Mbit/s

Syslog before/during problem (Don't have the exact time):

Mon Jun 17 17:12:21 2019 daemon.info hostapd: wlan1: STA 80:2b:f9:b5:b0:0f IEEE 802.11: authenticated
Mon Jun 17 17:12:21 2019 daemon.info hostapd: wlan1: STA 80:2b:f9:b5:b0:0f IEEE 802.11: associated (aid 5)
Mon Jun 17 17:12:21 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 80:2b:f9:b5:b0:0f
Mon Jun 17 17:12:21 2019 daemon.info hostapd: wlan1: STA 80:2b:f9:b5:b0:0f WPA: pairwise key handshake completed (RSN)
Mon Jun 17 17:12:21 2019 daemon.info dnsmasq-dhcp[1772]: DHCPREQUEST(br-lan) 192.168.66.162 80:2b:f9:b5:b0:0f
Mon Jun 17 17:12:21 2019 daemon.info dnsmasq-dhcp[1772]: DHCPACK(br-lan) 192.168.66.162 80:2b:f9:b5:b0:0f LAPTOP-JTAFJK8T
Mon Jun 17 17:12:22 2019 daemon.warn odhcpd[624]: DHCPV6 SOLICIT IA_NA from 000100012357de7ce86a6413b634 on br-lan: ok fdd9:21c2:f82d::a90/128
Mon Jun 17 17:12:22 2019 daemon.info dnsmasq[1772]: read /etc/hosts - 4 addresses
Mon Jun 17 17:12:22 2019 daemon.info dnsmasq[1772]: read /tmp/hosts/odhcpd - 2 addresses
Mon Jun 17 17:12:22 2019 daemon.info dnsmasq[1772]: read /tmp/hosts/dhcp.cfg01411c - 5 addresses
Mon Jun 17 17:12:22 2019 daemon.info dnsmasq-dhcp[1772]: read /etc/ethers - 0 addresses
Mon Jun 17 17:12:23 2019 daemon.warn odhcpd[624]: DHCPV6 REQUEST IA_NA from 000100012357de7ce86a6413b634 on br-lan: ok fdd9:21c2:f82d::a90/128
Mon Jun 17 17:12:23 2019 daemon.info dnsmasq[1772]: read /etc/hosts - 4 addresses
Mon Jun 17 17:12:23 2019 daemon.info dnsmasq[1772]: read /tmp/hosts/odhcpd - 3 addresses
Mon Jun 17 17:12:23 2019 daemon.info dnsmasq[1772]: read /tmp/hosts/dhcp.cfg01411c - 5 addresses
Mon Jun 17 17:12:23 2019 daemon.info dnsmasq-dhcp[1772]: read /etc/ethers - 0 addresses
Mon Jun 17 17:12:23 2019 daemon.warn odhcpd[624]: DHCPV6 RENEW IA_NA from 000100012357de7ce86a6413b634 on br-lan: ok fdd9:21c2:f82d::a90/128

Any specific reason that you are not using the current release 18.06.2 ?
(or even a snapshot from the current master)

I suggest that you start by updating to 18.06.2, which is 6 months newer than your current firmware.

1 Like

Good point, I will upgrade it.

Since the behavior is rather sporadic, are there any tools that I should add as well, to better capture the problem?

I still get problems after updating the router.

And hostapd shows no reason in the log. For one computer, it now clearly showed as being disconnected and then had to reconnect. For another, it just reported "No internet" (had no possibility to check if it still could ping the router, as I was not the one using the computer when it happened) and then had to be manually reconnected.

Tue Jun 25 17:47:12 2019 daemon.info hostapd: wlan1: STA 98:3b:8f:8c:d5:ed IEEE 802.11: authenticated
Tue Jun 25 17:47:12 2019 daemon.info hostapd: wlan1: STA 98:3b:8f:8c:d5:ed IEEE 802.11: associated (aid 7)
Tue Jun 25 17:47:12 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 98:3b:8f:8c:d5:ed
Tue Jun 25 17:47:12 2019 daemon.info hostapd: wlan1: STA 98:3b:8f:8c:d5:ed WPA: pairwise key handshake completed (RSN)
Tue Jun 25 17:47:27 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 98:3b:8f:8c:d5:ed
Tue Jun 25 17:47:34 2019 daemon.info hostapd: wlan1: STA 98:3b:8f:8c:d5:ed IEEE 802.11: authenticated
Tue Jun 25 17:47:34 2019 daemon.info hostapd: wlan1: STA 98:3b:8f:8c:d5:ed IEEE 802.11: associated (aid 7)
Tue Jun 25 17:47:34 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 98:3b:8f:8c:d5:ed

It's a long shot, but I found a topic about "disassoc_low_ack 0" and I will try that ( [SOLVED] "deauthenticated due to inactivity" after seconds ).

I also plan on testing different Wifi channels, but as far as I can tell, the neighbouring Wifis are on the same channel or a channel far away (no there should be good collision handling and no collisions, respectively). Possibly if there is a microwave or something disturbing Wifi, I guess.

edit.
I set TX power to max (20dBm) instead of "auto" and turned off 5 GHz wifi. So far, it seems to be stable. I the power output was the thing, as I had tried the clients on both 2.4 GHz and 5 GHz.

I am experiencing the same issue on the QCA9984 in a Turris Omnia. Although I am on 5GHz and ac.
Browsing the internet sometimes results in new page accesses having seconds of delay before pages load. The dreaded loading wheel. It happens spuriously, like lost packets, but pages always load in the end. Could be power management too, but don’t know how to debug it. I would appreciate if someone gave me pointers.

I am using ---OpenWrt 21.02-SNAPSHOT,

< ....Wed Mar 30 07:47:47 2022 daemon.notice netifd: up0v0 (2898): udhcpc: sending renew to 192.0.2.2
Wed Mar 30 07:47:47 2022 daemon.notice netifd: up0v0 (2898): udhcpc: lease of 172.31.255.10 obtained, lease time 600
Wed Mar 30 07:48:48 2022 daemon.info hostapd: wlan1: STA d4:8a:39:89:2e:0e IEEE 802.11: authenticated
Wed Mar 30 07:48:48 2022 daemon.info hostapd: wlan1: STA d4:8a:39:89:2e:0e IEEE 802.11: associated (aid 1)
Wed Mar 30 07:48:48 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED d4:8a:39:89:2e:0e 0 0
Wed Mar 30 07:48:48 2022 daemon.info hostapd: wlan1: STA d4:8a:39:89:2e:0e RADIUS: starting accounting session F813876670D23CC3
Wed Mar 30 07:48:48 2022 daemon.info hostapd: wlan1: STA d4:8a:39:89:2e:0e WPA: pairwise key handshake completed (RSN)
Wed Mar 30 07:48:48 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED d4:8a:39:89:2e:0e
Wed Mar 30 07:57:46 2022 daemon.notice netifd: up0v0 (2898): udhcpc: sending renew to 192.0.2.2
Wed Mar 30 07:57:46 2022 daemon.notice netifd: up0v0 (2898): udhcpc: lease of 172.31.255.10 obtained, lease time 600
Wed Mar 30 07:57:58 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED d4:8a:39:89:2e:0e 0 0
Wed Mar 30 07:57:58 2022 daemon.info hostapd: wlan1: STA d4:8a:39:89:2e:0e IEEE 802.11: disassociated due to inactivity
Wed Mar 30 07:57:59 2022 daemon.info hostapd: wlan1: STA d4:8a:39:89:2e:0e IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE
config wifi-iface 'up0v0_0_0'
        option ucentral_path '/interfaces/0/ssids/0'
        option device 'radio0'
        option network 'up0v0'
        option ssid 'RoamNetwork'
        option mode 'ap'
        option wds '0'
        option wpa_disable_eapol_key_retries '0'
        option disassoc_low_ack '0'
        option ieee80211w '2'
        option encryption 'psk2'
        option key '1234567890'
        option proxy_arp '1'
        option hidden '0'
        option isolate '0'
        option uapsd '0'
        option multicast_to_unicast '0'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option mobility_domain '519a'  ...  >

we are see this deauthenticated due to inactivity after second....please let me know any further inputs

Try the following...

Uncheck "Disable Inactivity Polling".

Increase the value in "Station inactivity limit".

I have a couple of static devices that were getting kicked when I didn't want them kicked, so that solved it.

Yes, thanks for the response..@anon89577378
I am new openwrt , let me know how we can set the above comments...!!

You can also try to increase timeout for the bridge mac table.
Either with brctl or in
LUCI -> Network -> Interfaces -> Devices (at the top) > "Your bridge interface" > Configure -> Advanced Setting -> Ageing Timeout

To like 14400 (4h)

If you have modified any ARP timeouts make sure they are lower or equal than the
mac ageing timeout.
For example with:

sysctl net.ipv4.neigh.default.base_reachable_time_ms=14400000
sysctl net.ipv6.neigh.default.base_reachable_time_ms=14400000

Defaults are 5min for the bridge mac table and ~30sec (is a bit randomized) for the ARP table.