ramips-mt7621: d-link-covr-x1860 - next node address not reachable through wifi

[maurerle]

Bug report

This issue occurs with v2023.2.x as well - just wanted to write it down for a reference.
It happens on the latest main branch as well occasionally.
I never experienced it in less crowded situations, so not all devices are affected..

What is the problem?

Sometimes, it occurs, that a COVR-X1860 has bad wifi for a few minutes.
Pinging the next-node IP-Adress times out.
The TQ stays stable.
After a few seconds (20-120s) the wifi works again and pings to the next node (or internet) are working again.

During occurance, I had a log of phy0 firmware, but not of phy1.
The problem occured on a node with client wifi on phy1 (5GHz) and mesh on phy0 (2.4).

logread from phy0 firmware debug log

Thu Feb 13 10:33:02 2025 kern.info kernel: [317695.847593] ieee80211 phy0: WM: (3911.372643:62:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail
Thu Feb 13 10:33:02 2025 kern.info kernel: [317695.856089] ieee80211 phy0: WM: (3911.372673:63:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail
Thu Feb 13 10:33:02 2025 kern.info kernel: [317695.864556] ieee80211 phy0: WM: (3911.372704:64:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail
Thu Feb 13 10:33:02 2025 kern.info kernel: [317695.873024] ieee80211 phy0: WM: (3911.375908:65:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail
Thu Feb 13 10:33:02 2025 kern.info kernel: [317695.881524] ieee80211 phy0: WM: (3911.375938:66:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail
Thu Feb 13 10:33:02 2025 kern.info kernel: [317695.890016] ieee80211 phy0: WM: (3911.375969:67:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail
Thu Feb 13 10:33:02 2025 kern.info kernel: [317695.898438] ieee80211 phy0: WM: (3911.376000:68:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail
Thu Feb 13 10:34:00 2025 kern.info kernel: [317753.420470] ieee80211 phy0: WM: (3968.976219:69:CMD-S)RfRegAccess!! Antenna = 0, Address = 0x0, Data = 0x3b8676e0
Thu Feb 13 10:34:00 2025 kern.info kernel: [317753.430991] ieee80211 phy0: WM: (3968.988884:70:CMD-S)RfRegAccess!! Antenna = 0, Address = 0x0, Data = 0x3b8676e0
Thu Feb 13 10:35:32 2025 kern.info kernel: [317846.250644] ieee80211 phy0: WM: (4061.811211:71:MQM-W)[WR] BSS usage overflows during removing entry
Thu Feb 13 10:35:32 2025 kern.info kernel: [317846.259949] ieee80211 phy0: WM: (4061.811333:72:BSS-E)_whCapSetGeneric_Falcon DW0 = 0x0, DW1 = 0x0
Thu Feb 13 10:35:32 2025 daemon.info hostapd: client1: STA a6:eb:b3:c3:38:cf IEEE 802.11: authenticated
Thu Feb 13 10:35:32 2025 kern.info kernel: [317846.274855] ieee80211 phy0: WM: (4061.835472:73:BSS-E)_whCapSetGeneric_Falcon DW0 = 0x0, DW1 = 0x0
Thu Feb 13 10:35:33 2025 kern.info kernel: [317846.284770] ieee80211 phy0: WM: (4061.845390:74:TXC-E)heACtrlInitStaRec(): prOperMode=401698, u2OperMode=41!
Thu Feb 13 10:35:33 2025 kern.info kernel: [317846.294768] ieee80211 phy0: WM: (4061.845421:75:BSS-E)muruAddStaRec, prRuStaRec->u1Bw = 0 eBand = 5000000 BSS BW = 0
Thu Feb 13 10:35:33 2025 daemon.info hostapd: client1: STA a6:eb:b3:c3:38:cf IEEE 802.11: associated (aid 3)
Thu Feb 13 10:35:33 2025 daemon.notice hostapd: client1: AP-STA-CONNECTED a6:eb:b3:c3:38:cf auth_alg=open
Thu Feb 13 10:35:33 2025 daemon.info hostapd: client1: STA a6:eb:b3:c3:38:cf RADIUS: starting accounting session DFF75ADC8F6B3EA0
Thu Feb 13 10:35:33 2025 kern.info kernel: [317846.309416] ieee80211 phy0: WM: (4061.870018:76:BSS-E)_whCapSetGeneric_Falcon DW0 = 0x0, DW1 = 0x0
Thu Feb 13 10:36:00 2025 kern.info kernel: [317873.387142] ieee80211 phy0: WM: (4088.932945:77:CMD-S)RfRegAccess!! Antenna = 0, Address = 0x0, Data = 0x3b8676e0
Thu Feb 13 10:36:00 2025 kern.info kernel: [317873.397657] ieee80211 phy0: WM: (4088.942223:78:CMD-S)RfRegAccess!! Antenna = 0, Address = 0x0, Data = 0x3b8676e0
Thu Feb 13 10:36:33 2025 daemon.notice hostapd: client1: AP-STA-DISCONNECTED da:79:50:51:9e:4c
Thu Feb 13 10:36:33 2025 daemon.info hostapd: client1: STA da:79:50:51:9e:4c IEEE 802.11: disassociated due to inactivity
Thu Feb 13 10:36:34 2025 daemon.info hostapd: client1: STA da:79:50:51:9e:4c IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Feb 13 10:36:34 2025 kern.info kernel: [317908.087846] ieee80211 phy0: WM: (4123.633141:79:MQM-W)[WR] BSS usage overflows during removing entry
Thu Feb 13 10:36:35 2025 daemon.notice hostapd: client1: AP-STA-DISCONNECTED 50:2f:9b:de:d8:8e
Thu Feb 13 10:36:35 2025 kern.info kernel: [317908.747395] ieee80211 phy0: WM: (4124.292595:80:MURU-E)[muruMumDeauthCheck] u2WlanIdx=7,u1ApNsts=2, u1StaNsts=2
Thu Feb 13 10:36:35 2025 kern.info kernel: [317908.757630] ieee80211 phy0: WM: (4124.292870:81:MQM-W)[WR] BSS usage overflows during removing entry
Thu Feb 13 10:36:42 2025 kern.info kernel: [317915.274834] ieee80211 phy0: WM: (4130.818382:82:MQM-W)[WR] BSS usage overflows during removing entry
Thu Feb 13 10:36:42 2025 kern.info kernel: [317915.284165] ieee80211 phy0: WM: (4130.818535:83:BSS-E)_whCapSetGeneric_Falcon DW0 = 0x0, DW1 = 0x0
Thu Feb 13 10:36:42 2025 daemon.info hostapd: client1: STA 50:2f:9b:de:d8:8e IEEE 802.11: authenticated
Thu Feb 13 10:36:42 2025 kern.info kernel: [317915.298085] ieee80211 phy0: WM: (4130.841667:84:BSS-E)_whCapSetGeneric_Falcon DW0 = 0x0, DW1 = 0x0
Thu Feb 13 10:36:42 2025 kern.info kernel: [317915.308359] ieee80211 phy0: WM: (4130.851799:85:TXC-E)heACtrlInitStaRec(): prOperMode=4013a0, u2OperMode=41!
Thu Feb 13 10:36:42 2025 kern.info kernel: [317915.318417] ieee80211 phy0: WM: (4130.851830:86:BSS-E)muruAddStaRec, prRuStaRec->u1Bw = 0 eBand = 5000000 BSS BW = 0
Thu Feb 13 10:36:42 2025 daemon.info hostapd: client1: STA 50:2f:9b:de:d8:8e IEEE 802.11: associated (aid 2)
Thu Feb 13 10:36:42 2025 daemon.notice hostapd: client1: AP-STA-CONNECTED 50:2f:9b:de:d8:8e auth_alg=open
Thu Feb 13 10:36:42 2025 kern.info kernel: [317915.334028] ieee80211 phy0: WM: (4130.877586:87:BSS-E)_whCapSetGeneric_Falcon DW0 = 0x0, DW1 = 0x0

I would suspect that this has to do with the lines BSS usage overflows during removing entry though I am quite unsure at the moment.
Will activate log for phy1 instead.

What is the expected behaviour?

even if wifi mesh is instable or something, the local nextnode ip of the node should not be affected and have a low latency.

It is especially hard for others, if the next node address does not work, so you can not get information about the device you are connected to, though we figured out, that it always is the nearest COVR in most cases.

Gluon Version:

7fbd7f8

Site Configuration:
ffac/site@21a20b0

Custom patches:
see site