tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

wifi: mac80211: reset CRC valid after CSA

While waiting for a beacon after CSA, reset the CRC valid
so that the next beacon is handled even if it happens to
be identical the last one on the old channel. This is an
AP bug either way, but it's better to disconnect cleanly
than to have lingering CSA state.

In the iwlwifi instantiation of this problem, mac80211 is
ignoring the beacon but the firmware creates a new CSA,
and then crashes later because mac80211/driver didn't do
anything about it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019115024.521ad9c6b87d.I86376900df3d3423185b75bf63358c29f33a5eb6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Johannes Berg 8f24be70 a3b16dfe

+10
+10
net/mac80211/mlme.c
··· 2508 2508 2509 2509 link->u.mgd.csa.waiting_bcn = true; 2510 2510 2511 + /* 2512 + * The next beacon really should always be different, so this should 2513 + * have no effect whatsoever. However, some APs (we observed this in 2514 + * an Asus AXE11000), the beacon after the CSA might be identical to 2515 + * the last beacon on the old channel - in this case we'd ignore it. 2516 + * Resetting the CRC will lead us to handle it better (albeit with a 2517 + * disconnect, but clearly the AP is broken.) 2518 + */ 2519 + link->u.mgd.beacon_crc_valid = false; 2520 + 2511 2521 /* apply new TPE restrictions immediately on the new channel */ 2512 2522 if (link->u.mgd.csa.ap_chandef.chan->band == NL80211_BAND_6GHZ && 2513 2523 link->u.mgd.conn.mode >= IEEE80211_CONN_MODE_HE) {