public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
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


  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