From: Johannes Berg <johannes@sipsolutions.net>
To: Shay Bar <Shay.Bar@celeno.com>, Ben Greear <greearb@candelatech.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] mac80211: Send deauth to STA's upon AP stop
Date: Thu, 25 Jun 2020 11:51:47 +0200 [thread overview]
Message-ID: <2a607392179a76f0f6fc3cef2e6e141f25dc0254.camel@sipsolutions.net> (raw)
In-Reply-To: <AM0P192MB0468ED699FC0BE6431812B03E7960@AM0P192MB0468.EURP192.PROD.OUTLOOK.COM>
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
next prev parent reply other threads:[~2020-06-25 9:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-18 9:36 [PATCH] mac80211: Send deauth to STA's upon AP stop Shay Bar
2020-06-18 13:47 ` Ben Greear
2020-06-18 13:48 ` Johannes Berg
2020-06-18 14:14 ` Shay Bar
2020-06-18 14:18 ` Johannes Berg
2020-06-18 14:36 ` Shay Bar
2020-06-18 14:38 ` Johannes Berg
2020-06-18 14:45 ` Shay Bar
2020-06-18 14:48 ` Johannes Berg
2020-06-18 15:11 ` Shay Bar
2020-06-18 15:26 ` Ben Greear
2020-06-21 10:12 ` Shay Bar
2020-06-25 9:51 ` Johannes Berg [this message]
2020-06-25 10:29 ` Shay Bar
2020-07-30 14:00 ` Johannes Berg
2020-07-30 14:23 ` Shay Bar
2020-07-30 14:28 ` Johannes Berg
2020-07-30 14:45 ` Shay Bar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a607392179a76f0f6fc3cef2e6e141f25dc0254.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Shay.Bar@celeno.com \
--cc=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox