From: Denis Kenzior <denkenz@gmail.com>
To: James Prestwood <prestwoj@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH v2 1/2] station: start roam on beacon loss event
Date: Tue, 7 Nov 2023 09:45:27 -0600 [thread overview]
Message-ID: <ced2eb2b-187f-4d4e-bffa-b1e8b46233ca@gmail.com> (raw)
In-Reply-To: <20231107141140.1706441-1-prestwoj@gmail.com>
Hi James,
On 11/7/23 08:11, James Prestwood wrote:
> Beacon loss handling was removed in the past because it was
> determined that this even always resulted in a disconnect. This
> was short sighted and not always true. The default kernel behavior
> waits for 7 lost beacons before emitting this event, then sends
> either a few nullfuncs or probe requests to the BSS to determine
> if its really gone. If these come back successfully the connection
> will remain alive. This can give IWD some time to roam in some
> cases so we should be handling this event.
>
> Since beacon loss indicates a very poor connection the roam scan
> is delayed by a few seconds in order to give the kernel a chance
> to send the nullfuncs/probes or receive more beacons. This may
> result in a disconnect, but it would have happened anyways.
> Attempting a roam mainly handles the case when the connection can
> be maintained after beacon loss, but is still poor.
> ---
> src/netdev.h | 1 +
> src/station.c | 18 ++++++++++++++++++
> 2 files changed, 19 insertions(+)
>
> v2:
> * Delay the roam to give the kernel a chance to salvage the
> connection
>
> FYI, I did attempt to add back the beacon loss test without much
> luck. Blocking beacons with hwsim did not result in a beacon loss
> event which may have been one of the reasons it was removed in the
> first place. Even blocking _all_ frames doesn't result in an event
> but instead just a local disconnect.
Good info, thanks for doing this. Guess we'll have to rely on manual testing
for this feature. :(
>
> After looking more into it I see that actually only a few drivers
> even use ieee80211_beacon_loss/ieee80211_connection_loss:
>
> iwlwifi,wl1251,intersil,mt76,wfx,ath10/11k,wcn36xx
>
> Every other driver likely disconnects rather than attempts to
> handle beacon loss. So probably for the majority of users this
> actually didn't matter, but for these drivers it does make sense
> to handle the event.
>
All applied, thanks.
Regards,
-Denis
prev parent reply other threads:[~2023-11-07 15:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 14:11 [PATCH v2 1/2] station: start roam on beacon loss event James Prestwood
2023-11-07 14:11 ` [PATCH v2 2/2] netdev: handle/send " James Prestwood
2023-11-07 15:45 ` Denis Kenzior [this message]
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=ced2eb2b-187f-4d4e-bffa-b1e8b46233ca@gmail.com \
--to=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=prestwoj@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.