[PATCH wireless-next] wifi: mac80211: Guard FILS discovery and unsolicited broadcast probe response

[PATCH wireless-next] wifi: mac80211: Guard FILS discovery and unsolicited broadcast probe response

[Manish Dharanenthiran]

According to IEEE Std 802.11-2024, subclause 11.45.2.1 FILS Discovery
frame transmission, only a transmitting BSS shall transmit a FILS
Discovery frame. Currently, BSS_CHANGED_FILS_DISCOVERY is set
unconditionally for all the BSSs. Hence, add a check to allow setting
the FILS Discovery flag only for a transmitting BSS.

Similarly, IEEE Std 802.11-2024, subclause 26.17.2.3.2 AP behavior for
fast passive scanning, mentions that unsolicited broadcast probe
response frame shall be transmitted only by a transmitting BSS. Hence,
add a check to allow setting the BSS_CHANGED_UNSOL_BCAST_PROBE_RESP only
for a transmitting BSS.

Signed-off-by: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>
---
 net/mac80211/cfg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 23f4f9ec86d0..8b6e2a400b5a 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1138,7 +1138,7 @@ static int ieee80211_set_fils_discovery(struct ieee80211_sub_if_data *sdata,
 	struct fils_discovery_data *new, *old = NULL;
 	struct ieee80211_fils_discovery *fd;
 
-	if (!params->update)
+	if (!params->update || link_conf->nontransmitted)
 		return 0;
 
 	fd = &link_conf->fils_discovery;
@@ -1173,7 +1173,7 @@ ieee80211_set_unsol_bcast_probe_resp(struct ieee80211_sub_if_data *sdata,
 {
 	struct unsol_bcast_probe_resp_data *new, *old = NULL;
 
-	if (!params->update)
+	if (!params->update || link_conf->nontransmitted)
 		return 0;
 
 	link_conf->unsol_bcast_probe_resp_interval = params->interval;

---
base-commit: ca800a9302764c445de0da0e84d2252400a770ee
change-id: 20260817-fils-d17716cc2781

Re: [PATCH wireless-next] wifi: mac80211: Guard FILS discovery and unsolicited broadcast probe response

[Johannes Berg]

On Thu, 2026-08-20 at 21:37 +0530, Manish Dharanenthiran wrote:
> 
> +++ b/net/mac80211/cfg.c
> @@ -1138,7 +1138,7 @@ static int ieee80211_set_fils_discovery(struct ieee80211_sub_if_data *sdata,
>  	struct fils_discovery_data *new, *old = NULL;
>  	struct ieee80211_fils_discovery *fd;
>  
> -	if (!params->update)
> +	if (!params->update || link_conf->nontransmitted)
>  		return 0;

So why shouldn't we just reject it?
 
>  	fd = &link_conf->fils_discovery;
> @@ -1173,7 +1173,7 @@ ieee80211_set_unsol_bcast_probe_resp(struct ieee80211_sub_if_data *sdata,
>  {
>  	struct unsol_bcast_probe_resp_data *new, *old = NULL;
>  
> -	if (!params->update)
> +	if (!params->update || link_conf->nontransmitted)
>  		return 0;

Same here.

johannes

Re: [PATCH wireless-next] wifi: mac80211: Guard FILS discovery and unsolicited broadcast probe response

[Manish Dharanenthiran]

On 9/4/2026 3:46 PM, Johannes Berg wrote:
> On Thu, 2026-08-20 at 21:37 +0530, Manish Dharanenthiran wrote:
>>
>> +++ b/net/mac80211/cfg.c
>> @@ -1138,7 +1138,7 @@ static int ieee80211_set_fils_discovery(struct ieee80211_sub_if_data *sdata,
>>   	struct fils_discovery_data *new, *old = NULL;
>>   	struct ieee80211_fils_discovery *fd;
>>   
>> -	if (!params->update)
>> +	if (!params->update || link_conf->nontransmitted)
>>   		return 0;
> 
> So why shouldn't we just reject it?
>   

Currently in user-space there is no restriction on sending this for 
non-transmitting BSS, thus it may send this for those BSSs as well, 
however the driver will use only for Tx BSS and ignore this config for 
Non-Tx BSS. Returning an error here could be fatal because failing 
start_ap or update_ap operation would result in failure of bringing up 
those BSSs.

We are working on the patch to update the behavior in hostap as well to 
not set this for Non-Tx BSS, but to maintain the backward compatibility, 
and the update from any other user-space application thus doesn't handle 
in a similar way, we ignored the update silently and kept as no-op.

Please let us know your thoughts.

>>   	fd = &link_conf->fils_discovery;
>> @@ -1173,7 +1173,7 @@ ieee80211_set_unsol_bcast_probe_resp(struct ieee80211_sub_if_data *sdata,
>>   {
>>   	struct unsol_bcast_probe_resp_data *new, *old = NULL;
>>   
>> -	if (!params->update)
>> +	if (!params->update || link_conf->nontransmitted)
>>   		return 0;
> 
> Same here.
> 
> johannes

-- 
- Manish D

Re: [PATCH wireless-next] wifi: mac80211: Guard FILS discovery and unsolicited broadcast probe response

[Johannes Berg]

On Thu, 2026-09-10 at 13:14 +0530, Manish Dharanenthiran wrote:
> 
> On 9/4/2026 3:46 PM, Johannes Berg wrote:
> > On Thu, 2026-08-20 at 21:37 +0530, Manish Dharanenthiran wrote:
> > > 
> > > +++ b/net/mac80211/cfg.c
> > > @@ -1138,7 +1138,7 @@ static int ieee80211_set_fils_discovery(struct ieee80211_sub_if_data *sdata,
> > >   	struct fils_discovery_data *new, *old = NULL;
> > >   	struct ieee80211_fils_discovery *fd;
> > >   
> > > -	if (!params->update)
> > > +	if (!params->update || link_conf->nontransmitted)
> > >   		return 0;
> > 
> > So why shouldn't we just reject it?
> >   
> 
> Currently in user-space there is no restriction on sending this for 
> non-transmitting BSS, thus it may send this for those BSSs as well, 
> however the driver will use only for Tx BSS and ignore this config for 
> Non-Tx BSS. Returning an error here could be fatal because failing 
> start_ap or update_ap operation would result in failure of bringing up 
> those BSSs.
> 
> We are working on the patch to update the behavior in hostap as well to 
> not set this for Non-Tx BSS, but to maintain the backward compatibility, 
> and the update from any other user-space application thus doesn't handle 
> in a similar way, we ignored the update silently and kept as no-op.

Then please document it at least in the commit message, but better also
in a comment here.

johannes

Re: [PATCH wireless-next] wifi: mac80211: Guard FILS discovery and unsolicited broadcast probe response

[Manish Dharanenthiran]

On 9/10/2026 1:40 PM, Johannes Berg wrote:
> On Thu, 2026-09-10 at 13:14 +0530, Manish Dharanenthiran wrote:
>>
>> On 9/4/2026 3:46 PM, Johannes Berg wrote:
>>> On Thu, 2026-08-20 at 21:37 +0530, Manish Dharanenthiran wrote:
>>>>
>>>> +++ b/net/mac80211/cfg.c
>>>> @@ -1138,7 +1138,7 @@ static int ieee80211_set_fils_discovery(struct ieee80211_sub_if_data *sdata,
>>>>    	struct fils_discovery_data *new, *old = NULL;
>>>>    	struct ieee80211_fils_discovery *fd;
>>>>    
>>>> -	if (!params->update)
>>>> +	if (!params->update || link_conf->nontransmitted)
>>>>    		return 0;
>>>
>>> So why shouldn't we just reject it?
>>>    
>>
>> Currently in user-space there is no restriction on sending this for
>> non-transmitting BSS, thus it may send this for those BSSs as well,
>> however the driver will use only for Tx BSS and ignore this config for
>> Non-Tx BSS. Returning an error here could be fatal because failing
>> start_ap or update_ap operation would result in failure of bringing up
>> those BSSs.
>>
>> We are working on the patch to update the behavior in hostap as well to
>> not set this for Non-Tx BSS, but to maintain the backward compatibility,
>> and the update from any other user-space application thus doesn't handle
>> in a similar way, we ignored the update silently and kept as no-op.
> 
> Then please document it at least in the commit message, but better also
> in a comment here.
> 
> johannes

Sure, will add a comment and send v2.

-- 
- Manish D