kernel/linux.git/net/wireless/mlme.c, branch linux-7.1.y

wifi: cfg80211: allow protected action frame TX for NAN

2026-03-25T19:56:56+00:00

Allow transmitting protected dual of public action frames on NAN device and NAN data interfaces, since NAN action frames may be protected and can be sent on both. Signed-off-by: Avraham Stern Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260318143604.73801a92180c.I16000c3e1e2bbc320457db1ac728d789bb2f36c6@changeid Signed-off-by: Johannes Berg

wifi: nl80211: allow reporting spurious NAN Data frames

2026-03-25T19:56:55+00:00

Currently we have this ability for AP and GO. But it is now needed also for NAN_DATA mode - as per Wi-Fi Aware (TM) 4.0 specification 6.2.5: "If a NAN Device receives a unicast NAN Data frame destined for it, but with A1 address and A2 address that are not assigned to the NDP, it shall discard the frame, and should send a Data Path Termination NAF to the frame transmitter" To allow this, change NL80211_CMD_UNEXPECTED_FRAME to support also NAN_DATA, so drivers can report such cases and the user space can act accordingly. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260108102921.5cf9f1351655.I47c98ce37843730b8b9eb8bd8e9ef62ed6c17613@changeid Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260219094725.3846371-6-miriam.rachel.korenblit@intel.com Link: https://patch.msgid.link/20260318123926.206536-9-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg

wifi: cfg80211: events, report background radar

2026-03-02T08:10:28+00:00

In case we report radar event add also information this is connected with background one, so user mode application like hostapd, could check it and behave correctly. Signed-off-by: Janusz Dziedzic Link: https://patch.msgid.link/20260206171830.553879-4-janusz.dziedzic@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: set and report chandef CAC ongoing

2026-03-02T08:10:28+00:00

Allow to track and check CAC state from user mode by simple check phy channels eg. using iw phy1 channels command. This is done for regular CAC and background CAC. It is important for background CAC while we can start it from any app (eg. iw or hostapd). Signed-off-by: Janusz Dziedzic Link: https://patch.msgid.link/20260206171830.553879-3-janusz.dziedzic@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: fix background CAC

2026-03-02T08:10:28+00:00

Fix: - Send CAC_ABORT event when background CAC is canceled - Cancel CAC done workqueue when radar is detected - Release background wdev ownership when CAC is aborted or passed - Clean lower layer background radar state when CAC is aborted or passed - Prevent sending abort event when radar event is sent Signed-off-by: Janusz Dziedzic Link: https://patch.msgid.link/20260206171830.553879-2-janusz.dziedzic@gmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: stop radar detection in cfg80211_leave()

2025-11-24T12:05:23+00:00

If an interface is set down or, per the previous patch, changes type, radar detection for it should be cancelled. This is done for AP mode in mac80211 (somewhat needlessly, since cfg80211 can do it, but didn't until now), but wasn't handled for mesh, so if radar detection was started and then the interface set down or its type switched (the latter sometimes happning in the hwsim test 'mesh_peer_connected_dfs'), radar detection would be around with the interface unknown to the driver, later leading to some warnings around chanctx usage. Link: https://patch.msgid.link/20251121174021.290120e419e3.I2a5650c9062e29c988992dd8ce0d8eb570d23267@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: reject HTC bit for management frames

2025-07-21T17:35:45+00:00

Management frames sent by userspace should never have the order/HTC bit set, reject that. It could also cause some confusion with the length of the buffer and the header so the validation might end up wrong. Link: https://patch.msgid.link/20250718202307.97a0455f0f35.I1805355c7e331352df16611839bc8198c855a33f@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: only verify part of Extended MLD Capabilities

2025-07-09T09:52:35+00:00

We verify that the Extended MLD Capabilities are matching between links. However, some bits are reserved and in particular the Recommended Max Links subfield may not necessarily match. So only verify the known subfields that can reliably be expected to be the same. More information can be found in Table 9-417o, in IEEE P802.11be/D7.0. Signed-off-by: Benjamin Berg Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250609213231.a2fad48dd3e6.Iae1740cd2ac833bc4a64fd2af718e1485158fd42@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: Add support for link reconfiguration negotiation offload to driver

2025-06-20T08:46:31+00:00

In the case of SME-in-driver, the driver can internally choose to update the links based on the AP MLD recommendation and do link reconfiguration negotiation with AP MLD. (e.g., After the driver processing the BSS Transition Management request frame received from the AP MLD with Neighbor Report containing Multi-Link element with recommended links information chooses to do link reconfiguration negotiation with AP MLD). To support this, extend cfg80211_mlo_reconf_add_done() and NL80211_CMD_ASSOC_MLO_RECONF to indicate added links information for driver-initiated link reconfiguration requests. For removed links, the driver indicates links information using the NL80211_CMD_LINKS_REMOVED event for driver-initiated cases, the same as supplicant initiated cases. For the driver-initiated case, cfg80211 will receive link reconfiguration result asynchronously from driver so holding BSSes of the accepted add links is needed in the event path. Also, no need of unhold call for the rejected add link BSSes since there was no hold call happened previously. Once the supplicant receives the NL80211_CMD_ASSOC_MLO_RECONF event, it needs to process the information about newly added links and install per-link group keys (e.g., GTK/IGTK/BIGTK etc.). In case of the SME-in-driver, using a vendor interface etc. to notify the supplicant to initiate a link reconfiguration request and then supplicant sending command to the cfg80211 can lead to race conditions. The correct design to avoid this is that the driver indicates the cfg80211 directly with the results of the link reconfiguration negotiation. Signed-off-by: Kavita Kavita Link: https://patch.msgid.link/20250604105757.2542-3-quic_kkavita@quicinc.com Signed-off-by: Johannes Berg

wifi: cfg80211: Update the link address when a link is added

2025-03-11T09:53:10+00:00

When links are added, update the wireless device link addresses based on the information provided by the driver. Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308225541.d694a9125aba.I79b010ea9aab47893e4f22c266362fde30b7f9ac@changeid Signed-off-by: Johannes Berg