13:53 <f00b4r0> nbd: in case this is relevant, I started noticing some 'system' CPU spikes that did not correlate with increased throughput on the device

13:54 <f00b4r0> looking at the logs, they seem to correlate with very large (1000s) bursts of "ieee80211 phy0: WM: ( 230.194785:16:MURU-E)[muruSwPpduDurAdapt] score = 0 Fail" messages

17:13 <nbd> f00b4r0: interesting. any resets so far?

17:14 <f00b4r0> apparently none

17:14 <nbd> cool

17:15 <nbd> i think what may have reduced the occurence is "wifi: mt76: mt7915: use mac80211 .sta_state op"

17:15 <nbd> i already suspected that there might be some race condition on wcid reuse during disconnect and that this might be tripping up the firmware

17:16 <nbd> i think the above commit makes this race a lot less likely (or maybe even impossible)

17:16 <f00b4r0> ok. it's a bit early to call a victory though, in the past the longest uptime was c. 2 weeks :)

17:16 <nbd> ok

17:20 <f00b4r0> the cpu spikes are definitely a new thing since trying latest code. Dunno if it's a consequence of enabling debug or if debug just tells us what causes it

19:38 <cmonroe_> nbd: i’m not sure why yet, but mt76 commit 891031ee (add separate tx scheduling queue for off-channel tx) seems to break radios in STA mode connecting to a hidden VAP. wpa_cli scan_results shows the hidden network BSSID in the list but the ESSID never shows up.. I assume this means the probe request is either not being set or response not being received?

19:44 <f00b4r0> cmonroe_: may or may not be related but I noticed that my only wpasupplicant client that connects to a hidden SSID stopped working after the last wpasupplicant update (in Debian, the one that fixed a couple CVEs).

19:44 <f00b4r0> i haven't dug into that oddity.

19:46 <cmonroe_> f00b4r0: oops! thanks for the heads up, i'm guessing i should run into that too next time hostapd is bumped. in this case i bisected the current failure down to the commit i mentioned above on top of openwrt master from today. commit b80c997b directly before the one mentioned above works ok.

19:47 <cmonroe_> at some point i need to move away from using hidden VAPs but it's nice to hide the ones used for mesh backhaul. would be better to just do backhaul on top of the primary vap though i think.

20:15 <schmars[m]> oh yeah i've seen the same thing with wpa\_supplicant on fedora 40, i did `dnf downgrade wpa_supplicant`

20:17 <f00b4r0> ah so it's not just my imagination. good to know

20:17 <schmars[m]> ah no my thing seems related to broadcom client (macbook), but anyway needed to downgrade to previous release. nevermind, carry on

20:18 <schmars[m]> my thing is that scanning doesn't work on the macbook unless you manually do `iw dev wlp123 scan`

20:19 <f00b4r0> incidentally, my failing client is also bcm: raspi

20:20 <schmars[m]> :-)

20:21 <schmars[m]> i didn't investigate further, it was just an old macbook i prepared for a friend, and wpa_supplicant downgrade was enough for me

21:14 <schmars[m]> running my three mt7915e APs with fw_debug_wm now

21:17 <schmars[m]> well the third not yet - it's in "crash immediately" mode right now and has only a few seconds uptime when it gets rebooted at :06 every hour

23:03 <mrkiko> schmars[m]: sorry for the possibly dumb question - are you using the latest mt7915 firmware?

23:03 <mrkiko> seen an update for it just now

23:03 <mrkiko> I'm back! :)