[PATCH] mac80211: Send deauth to STA's upon AP stop

[PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

In current code, AP is not informing STA when its going down.
So STA keep looking the AP (Null function etc.) and can't find it (it is down).

Fix is to send deauth to all associated STA's upon AP stop.
__sta_info_flush() with a true bool is only called from ieee80211_stop_ap().
Rename "vlans" -> "ap_stop".

Signed-off-by: Shay Bar <shay.bar@celeno.com>
---
 net/mac80211/sta_info.c | 20 ++++++++++++++++----
 net/mac80211/sta_info.h |  5 +++--
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index cd8487bc6fc2..46b26e66430a 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1179,7 +1179,7 @@ void sta_info_stop(struct ieee80211_local *local)
 }
 
 
-int __sta_info_flush(struct ieee80211_sub_if_data *sdata, bool vlans)
+int __sta_info_flush(struct ieee80211_sub_if_data *sdata, bool ap_stop)
 {
 	struct ieee80211_local *local = sdata->local;
 	struct sta_info *sta, *tmp;
@@ -1188,13 +1188,25 @@ int __sta_info_flush(struct ieee80211_sub_if_data *sdata, bool vlans)
 
 	might_sleep();
 
-	WARN_ON(vlans && sdata->vif.type != NL80211_IFTYPE_AP);
-	WARN_ON(vlans && !sdata->bss);
+	WARN_ON(ap_stop && sdata->vif.type != NL80211_IFTYPE_AP);
+	WARN_ON(ap_stop && !sdata->bss);
 
 	mutex_lock(&local->sta_mtx);
 	list_for_each_entry_safe(sta, tmp, &local->sta_list, list) {
 		if (sdata == sta->sdata ||
-		    (vlans && sdata->bss == sta->sdata->bss)) {
+		    (ap_stop && sdata->bss == sta->sdata->bss)) {
+			if (ap_stop) {
+				u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN];
+				u16 stype = IEEE80211_STYPE_DEAUTH;
+				u16 reason = WLAN_REASON_DEAUTH_LEAVING;
+				ieee80211_send_deauth_disassoc(sdata,
+							       sta->sta.addr,
+							       sdata->vif.addr,
+							       stype,
+							       reason,
+							       true,
+							       frame_buf);
+			}
 			if (!WARN_ON(__sta_info_destroy_part1(sta)))
 				list_add(&sta->free_list, &free_list);
 			ret++;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 49728047dfad..f0aedfa221c2 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -789,9 +789,10 @@ void sta_info_stop(struct ieee80211_local *local);
  * Returns the number of removed STA entries.
  *
  * @sdata: sdata to remove all stations from
- * @vlans: if the given interface is an AP interface, also flush VLANs
+ * @ap_stop: if the given interface is an AP being stopped, we should send
+ * deauth to STA's and flush VLANs
  */
-int __sta_info_flush(struct ieee80211_sub_if_data *sdata, bool vlans);
+int __sta_info_flush(struct ieee80211_sub_if_data *sdata, bool ap_stop);
 
 static inline int sta_info_flush(struct ieee80211_sub_if_data *sdata)
 {
-- 
2.17.1

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Ben Greear]

On 06/18/2020 02:36 AM, Shay Bar wrote:
> In current code, AP is not informing STA when its going down.
> So STA keep looking the AP (Null function etc.) and can't find it (it is down).

Hello,

It will take a noticeable amount of time to send deauth to hundreds of stations
in cases where a busy AP goes down.  Is there any clever way to use something like
11k/v to send a single frame to let all stations know AP is going down?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Johannes Berg]

On Thu, 2020-06-18 at 12:36 +0300, Shay Bar wrote:
> In current code, AP is not informing STA when its going down.
> 
Hostapd normally handles that. Are we really so worried about it
crashing?

johannes

RE: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

> Hostapd normally handles that. Are we really so worried about it
> crashing?
> johannes

Actually, it's not crashing but WIFI STA keeps sending unicast frames
to AP such as RTS, BAR, NULL function (no data).
This is what I want to avoid.
Its just seems much more clever to let STA know we are down.
don’t you agree?
Once it receive this deauth, STA stop sending any frames to AP.
Shay.
________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Johannes Berg]

On Thu, 2020-06-18 at 14:14 +0000, Shay Bar wrote:
> > Hostapd normally handles that. Are we really so worried about it
> > crashing?
> > johannes
> 
> Actually, it's not crashing but WIFI STA keeps sending unicast frames
> to AP such as RTS, BAR, NULL function (no data).
> This is what I want to avoid.
> Its just seems much more clever to let STA know we are down.
> don’t you agree?

We're doing that. More accurately, hostapd is doing that. So what's not
working for you?

johannes

RE: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

> We're doing that. More accurately, hostapd is doing that. So what's not
> working for you?
> johannes

Air capture shows, hostapd doesn’t send deauth in the below 2 cases and I
actually don't see such hostapd code that handles that:
"ifconfig <if> down"
"killall hostapd"

Am I missing something?
________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Johannes Berg]

On Thu, 2020-06-18 at 14:36 +0000, Shay Bar wrote:
> > We're doing that. More accurately, hostapd is doing that. So what's not
> > working for you?
> > johannes
> 
> Air capture shows, hostapd doesn’t send deauth in the below 2 cases and I
> actually don't see such hostapd code that handles that:
> "ifconfig <if> down"
> "killall hostapd"

So... why would you ever do that? :)

johannes

RE: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

> So... why would you ever do that? :)
> johannes

:)
Is it illegal to do "ifconfig <if> down" or kill hostapd
while STA's are still associated?
There are some vendors/users that are doing that.

Regarding Ben's proposal of using 11k/v, I couldn’t find such
"going down" single frame in the standard (although sounds trivial)

Shay.
________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Johannes Berg]

On Thu, 2020-06-18 at 14:45 +0000, Shay Bar wrote:
> > So... why would you ever do that? :)
> > johannes
> 
> :)
> Is it illegal to do "ifconfig <if> down" or kill hostapd
> while STA's are still associated?
> There are some vendors/users that are doing that.

It's not really *illegal* per se, but it would be weird if both did it
... But I do tend to think that if you're using hostapd or such to
control it, you shouldn't do another out-of-band control.

> Regarding Ben's proposal of using 11k/v, I couldn’t find such
> "going down" single frame in the standard (although sounds trivial)

Broadcast deauth :)

johannes

RE: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

>> Is it illegal to do "ifconfig <if> down" or kill hostapd
>> while STA's are still associated?
>> There are some vendors/users that are doing that.

> It's not really *illegal* per se, but it would be weird if both did it
> ... But I do tend to think that if you're using hostapd or such to
> control it, you shouldn't do another out-of-band control.

Maybe I was misunderstood, using _any_ one of the above methods
to down the interface, have the same result -
hostapd doesn’t send any deauth and STA's stay unaware of AP down.

Shay.
________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Ben Greear]

On 06/18/2020 07:48 AM, Johannes Berg wrote:
> On Thu, 2020-06-18 at 14:45 +0000, Shay Bar wrote:
>>> So... why would you ever do that? :)
>>> johannes
>>
>> :)
>> Is it illegal to do "ifconfig <if> down" or kill hostapd
>> while STA's are still associated?
>> There are some vendors/users that are doing that.
>
> It's not really *illegal* per se, but it would be weird if both did it
> ... But I do tend to think that if you're using hostapd or such to
> control it, you shouldn't do another out-of-band control.
>
>> Regarding Ben's proposal of using 11k/v, I couldn’t find such
>> "going down" single frame in the standard (although sounds trivial)
>
> Broadcast deauth :)

Or use k/v to tell STA that AP is going down immediately and here is (null, likely)
list of APs to associate with instead?

Another thing I notice:  In order to keep things from blocking for long periods (3+ seconds)
with rtnl held, I ended up doing a force flush in ath10k-ct, so at least when using that
driver, sending frames and then immediately doing flush will likely not put much on air.

I have hoped to one day add tx-completion call-backs handling to mac80211 instead of just calling a flush
for these types of station-down communication where flush is to be called shortly.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

RE: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

Hi Johannes and Ben,

To conclude this thread, hostapd doesn’t send any deauth/disassoc
upon AP stop (when hostapd is killed _or_ when "ifconfig down" the
AP interface).
This is causing a situation where stations keep sending unicast frames
to a down AP interface as it doesn’t know it's gone down.
I tried your suggestion and sent 1 deauth/disassoc as broadcast
(instead of unicast to each STA), but some stations (e.g. Samsung S8)
Ignore this broadcast (while it will not ignore unicast deauth/disassoc).
Although not indicated in the standard, I think it's better to let STA
Know AP gone down by sending this unicast deauth to each STA
(as this patch does).

Please let me know your decision.
Shay.
________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Johannes Berg]

On Sun, 2020-06-21 at 10:12 +0000, Shay Bar wrote:
> Hi Johannes and Ben,
> 
> To conclude this thread, hostapd doesn’t send any deauth/disassoc
> upon AP stop (when hostapd is killed _or_ when "ifconfig down" the
> AP interface).

Right. I'm sort of suggesting you just shouldn't be doing this, and it
doesn't seem like most people actually do, otherwise we'd have seen this
issue before?

> This is causing a situation where stations keep sending unicast frames
> to a down AP interface as it doesn’t know it's gone down.
> I tried your suggestion and sent 1 deauth/disassoc as broadcast
> (instead of unicast to each STA), but some stations (e.g. Samsung S8)
> Ignore this broadcast (while it will not ignore unicast deauth/disassoc).
> Although not indicated in the standard, I think it's better to let STA
> Know AP gone down by sending this unicast deauth to each STA
> (as this patch does).

I'm not really sure. That's a _lot_ of frames and potentially quite a
long time. In the patch, as written, I'm not even convinced you can be
sure that they will all make it out to the air?

johannes

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

On 25/06/2020 12:51, Johannes Berg wrote:
> External Email
>
>
> On Sun, 2020-06-21 at 10:12 +0000, Shay Bar wrote:
>> Hi Johannes and Ben,
>>
>> To conclude this thread, hostapd doesn’t send any deauth/disassoc
>> upon AP stop (when hostapd is killed _or_ when "ifconfig down" the
>> AP interface).
>
> Right. I'm sort of suggesting you just shouldn't be doing this, and it
> doesn't seem like most people actually do, otherwise we'd have seen this
> issue before?
>
I shouldn't kill hostapd? Isn't this a very basic action?
What is the alternative for stopping the AP?

>> This is causing a situation where stations keep sending unicast frames
>> to a down AP interface as it doesn’t know it's gone down.
>> I tried your suggestion and sent 1 deauth/disassoc as broadcast
>> (instead of unicast to each STA), but some stations (e.g. Samsung S8)
>> Ignore this broadcast (while it will not ignore unicast deauth/disassoc).
>> Although not indicated in the standard, I think it's better to let STA
>> Know AP gone down by sending this unicast deauth to each STA
>> (as this patch does).
>
> I'm not really sure. That's a _lot_ of frames and potentially quite a
> long time. In the patch, as written, I'm not even convinced you can be
> sure that they will all make it out to the air?
I agree, but what's the alternative?

Thanks,
Shay
________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Johannes Berg]

On Thu, 2020-06-25 at 13:29 +0300, Shay Bar wrote:
> On 25/06/2020 12:51, Johannes Berg wrote:
> > External Email
> > 
> > 
> > On Sun, 2020-06-21 at 10:12 +0000, Shay Bar wrote:
> > > Hi Johannes and Ben,
> > > 
> > > To conclude this thread, hostapd doesn’t send any deauth/disassoc
> > > upon AP stop (when hostapd is killed _or_ when "ifconfig down" the
> > > AP interface).
> > 
> > Right. I'm sort of suggesting you just shouldn't be doing this, and it
> > doesn't seem like most people actually do, otherwise we'd have seen this
> > issue before?
> > 
> I shouldn't kill hostapd? Isn't this a very basic action?
> What is the alternative for stopping the AP?

I guess I would say to use hostapd_cli first to "disable" the
interfaces?

johannes

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

On 30/07/2020 17:00, Johannes Berg wrote:
> External Email
>
>
> On Thu, 2020-06-25 at 13:29 +0300, Shay Bar wrote:
>> On 25/06/2020 12:51, Johannes Berg wrote:
>>> External Email
>>>
>>>
>>> On Sun, 2020-06-21 at 10:12 +0000, Shay Bar wrote:
>>>> Hi Johannes and Ben,
>>>>
>>>> To conclude this thread, hostapd doesn’t send any deauth/disassoc
>>>> upon AP stop (when hostapd is killed _or_ when "ifconfig down" the
>>>> AP interface).
>>> Right. I'm sort of suggesting you just shouldn't be doing this, and it
>>> doesn't seem like most people actually do, otherwise we'd have seen this
>>> issue before?
>>>
>> I shouldn't kill hostapd? Isn't this a very basic action?
>> What is the alternative for stopping the AP?
> I guess I would say to use hostapd_cli first to "disable" the
> interfaces?

Indeed, using hostapd_cli "DISABLE" will call hostapd_flush_old_stations() that will send broadcast deauth.
The problem is (mentioned before) that some stations (e.g. Samsung S8) ignore this broadcast (while it will not ignore unicast deauth/disassoc).

________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Johannes Berg]

On Thu, 2020-07-30 at 14:23 +0000, Shay Bar wrote:
> On 30/07/2020 17:00, Johannes Berg wrote:
> > External Email
> > 
> > 
> > On Thu, 2020-06-25 at 13:29 +0300, Shay Bar wrote:
> > > On 25/06/2020 12:51, Johannes Berg wrote:
> > > > External Email
> > > > 
> > > > 
> > > > On Sun, 2020-06-21 at 10:12 +0000, Shay Bar wrote:
> > > > > Hi Johannes and Ben,
> > > > > 
> > > > > To conclude this thread, hostapd doesn’t send any deauth/disassoc
> > > > > upon AP stop (when hostapd is killed _or_ when "ifconfig down" the
> > > > > AP interface).
> > > > Right. I'm sort of suggesting you just shouldn't be doing this, and it
> > > > doesn't seem like most people actually do, otherwise we'd have seen this
> > > > issue before?
> > > > 
> > > I shouldn't kill hostapd? Isn't this a very basic action?
> > > What is the alternative for stopping the AP?
> > I guess I would say to use hostapd_cli first to "disable" the
> > interfaces?
> 
> Indeed, using hostapd_cli "DISABLE" will call
> hostapd_flush_old_stations() that will send broadcast deauth.

Ah.

> The problem is (mentioned before) that some stations (e.g. Samsung S8)
> ignore this broadcast (while it will not ignore unicast
> deauth/disassoc).

Right, you mentioned that. I guess you could work around by disabling
all stations separately, but ... not really a great solution either.

Perhaps we should fix that at the hostapd level?

Not really sure how much trouble we should go to for bad stations
though. I mean, it's not like they should be ignoring that.

Maybe they just miss it due to super aggressive powersave, and we should
send it a few times?

johannes

Re: [PATCH] mac80211: Send deauth to STA's upon AP stop

[Shay Bar]

On 30/07/2020 17:28, Johannes Berg wrote:
> External Email
>
>
> On Thu, 2020-07-30 at 14:23 +0000, Shay Bar wrote:
>> On 30/07/2020 17:00, Johannes Berg wrote:
>>> External Email
>>>
>>>
>>> On Thu, 2020-06-25 at 13:29 +0300, Shay Bar wrote:
>>>> On 25/06/2020 12:51, Johannes Berg wrote:
>>>>> External Email
>>>>>
>>>>>
>>>>> On Sun, 2020-06-21 at 10:12 +0000, Shay Bar wrote:
>>>>>> Hi Johannes and Ben,
>>>>>>
>>>>>> To conclude this thread, hostapd doesn’t send any deauth/disassoc
>>>>>> upon AP stop (when hostapd is killed _or_ when "ifconfig down" the
>>>>>> AP interface).
>>>>> Right. I'm sort of suggesting you just shouldn't be doing this, and it
>>>>> doesn't seem like most people actually do, otherwise we'd have seen this
>>>>> issue before?
>>>>>
>>>> I shouldn't kill hostapd? Isn't this a very basic action?
>>>> What is the alternative for stopping the AP?
>>> I guess I would say to use hostapd_cli first to "disable" the
>>> interfaces?
>> Indeed, using hostapd_cli "DISABLE" will call
>> hostapd_flush_old_stations() that will send broadcast deauth.
> Ah.
>
>> The problem is (mentioned before) that some stations (e.g. Samsung S8)
>> ignore this broadcast (while it will not ignore unicast
>> deauth/disassoc).
> Right, you mentioned that. I guess you could work around by disabling
> all stations separately, but ... not really a great solution either.
>
> Perhaps we should fix that at the hostapd level?
>
> Not really sure how much trouble we should go to for bad stations
> though. I mean, it's not like they should be ignoring that.
>
> Maybe they just miss it due to super aggressive powersave, and we should
> send it a few times?

Power save is possible.
I will try sending it 3 times (instead of only 1) and see if it helps.
Anyway, I agree we should not put extra effort for STA's that ignore this bcast,
Lets discard this patch.

Thanks.

________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________