From: James Prestwood <prestwoj@gmail.com>
To: iwd@lists.linux.dev
Cc: James Prestwood <prestwoj@gmail.com>
Subject: [PATCH 0/4] Packet/beacon loss roaming improvements
Date: Mon, 30 Oct 2023 06:48:33 -0700 [thread overview]
Message-ID: <20231030134837.452957-1-prestwoj@gmail.com> (raw)
The rate limiting patch shouldn't be too controversial, but the
forced roam on beacon loss may be so I wanted to provde some
background. This behavior was only tested on ath10k, so I understand
if we don't want to impose the same behavior for all drivers.
We were seeing beacon loss events not resulting in an immediate
disconnnect (as I have always expected), still eventually but after
plenty of time to roam. I initially added handling for
beacon loss identical to packet loss (try and find a better BSS) but
noticed that if IWD did not find a better candidate it resulted in a
disconnect 100% of the time. I watched a client for a full day and
whenever beacon loss events arrived they were followed by a
disconnect within ~5-6 seconds if IWD did not roam. This led me to
believe that at least on ath10k a beacon loss is still very much a
sign that a disconnect is going to come, we just have a bit more time
than other drivers. This was the motivation behind re-using/re-naming
the 'ap_directed_roam' flag in order to force IWD off the BSS.
Again, this is just one driver. Maybe other drivers can
handle/recover from beacon loss. If we instead want to keep the
behavior the same as packet loss I'm ok with that (I can keep the
patch locally), or put the forced roam behavior behind a user
option e.g. [Roam].ForceRoamOnBeaconLoss
James Prestwood (4):
station: rename ap_directed_roam to force_roam
station: start roam on beacon loss event
netdev: handle/send beacon loss event
station: rate limit packet loss roam scans
src/netdev.c | 6 ++++-
src/netdev.h | 1 +
src/station.c | 61 +++++++++++++++++++++++++++++++++++++++++++--------
3 files changed, 58 insertions(+), 10 deletions(-)
--
2.25.1
next reply other threads:[~2023-10-30 13:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 13:48 James Prestwood [this message]
2023-10-30 13:48 ` [PATCH 1/4] station: rename ap_directed_roam to force_roam James Prestwood
2023-10-30 13:48 ` [PATCH 2/4] station: start roam on beacon loss event James Prestwood
2023-10-30 13:48 ` [PATCH 3/4] netdev: handle/send " James Prestwood
2023-10-30 13:48 ` [PATCH 4/4] station: rate limit packet loss roam scans James Prestwood
2023-10-30 14:48 ` Denis Kenzior
2023-10-30 15:00 ` [PATCH 0/4] Packet/beacon loss roaming improvements Denis Kenzior
2023-10-30 15:37 ` James Prestwood
2023-10-30 17:05 ` Denis Kenzior
2023-10-30 17:37 ` James Prestwood
2023-11-01 12:07 ` James Prestwood
2023-11-02 1:39 ` Denis Kenzior
2023-11-02 11:58 ` James Prestwood
2023-11-02 14:10 ` Denis Kenzior
2023-11-02 14:33 ` James Prestwood
2023-11-02 15:17 ` Denis Kenzior
2023-11-02 15:41 ` James Prestwood
2023-11-02 16:10 ` Denis Kenzior
2023-11-02 16:13 ` James Prestwood
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=20231030134837.452957-1-prestwoj@gmail.com \
--to=prestwoj@gmail.com \
--cc=iwd@lists.linux.dev \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).