Re: [PATCH wireless-next 4/7] wifi: mac80211: nan: allow Rx registration for NAN beacons

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-10-01 at 16:33 +0300, Miri Korenblit wrote:
> From: Ilan Peer <ilan.peer@intel.com>
> 
> Instant Communication requires user space to track the NAN beacons, so
> let it register for Rx of beacons on a NAN interface. Add support for
> passing beacon on NAN Device interface when instant communication is
> enabled.
> 
> Add a helper function to identify NAN beacons, based on the BSSID
> and the beacon frame content. Skip NAN beacons so they would not
> be used to update the BSS table.

This does two things, please split it.


> +++ b/net/mac80211/rx.c
> @@ -4536,7 +4536,10 @@ static bool ieee80211_accept_frame(struct ieee80211_rx_data *rx)
>  	struct ieee80211_hdr *hdr = (void *)skb->data;
>  	struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
>  	u8 *bssid = ieee80211_get_bssid(hdr, skb->len, sdata->vif.type);
> +	bool nan_beacon = ieee80211_is_nan_beacon((struct ieee80211_mgmt *)hdr,
> +						  skb->len);

Doing that fairly long inline here for every single frame seems like a
bad idea. It's also really not necessary at this spot, we accept just
about every beacon frame here and today even every NAN beacon if it
bubbles up. Also, BSSID filter will reject it anyway in most cases, so
is it even needed at all?

We can always be attacked in some way with this, so that's not an excuse
either, could even trivially just put a non-vendor-element into what
otherwise looks like a NAN beacon and then it'd be rejected by
"is_nan_beacon()" but parse exactly the same way as one.

> --- a/net/mac80211/scan.c
> +++ b/net/mac80211/scan.c
> @@ -353,6 +353,10 @@ void ieee80211_scan_rx(struct ieee80211_local *local, struct sk_buff *skb)
>  		if (!ieee80211_is_s1g_beacon(mgmt->frame_control) &&
>  		    !is_broadcast_ether_addr(mgmt->da))
>  			return;
> +
> +		/* NAN beacons are not a BSS, don't add to the BSS table */
> +		if (ieee80211_is_nan_beacon(mgmt, skb->len))
> +			return;

If that's such a hard general rule, why in mac80211?

johannes