Reject authentication start during explicit roam requests

The roam D-Bus and ROAM control itnerface commands flip the reassociate
bit before calling wpa_supplicant_connect(). wpa_supplicant connect
eventually aborts ongoing scans (if any), which causes scan results to
be reported. Since the reassociate bit is set, this will trigger a
connection attempt based on the aborted scan's scan results and cancel
the initial connetion request. This often causes wpa_supplicant to
reassociate to the same AP it is currently associated to instead of the
explicitly requested roaming target.

Add a roam_in_progress flag to indicate that we're currently attempting
to roam via an explicitly request to a specific BSS so that we don't
initiate another connection attempt based on the possibly received scan
results from a scan that was in progress at the time the roam command
was received.

Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
This commit is contained in:
Matthew Wang 2021-03-05 17:43:44 -08:00 committed by Jouni Malinen
parent 800fb69970
commit 5ac977758d
4 changed files with 28 additions and 0 deletions

View file

@ -941,6 +941,8 @@ static void sme_auth_start_cb(struct wpa_radio_work *work, int deinit)
struct wpa_connect_work *cwork = work->ctx;
struct wpa_supplicant *wpa_s = work->wpa_s;
wpa_s->roam_in_progress = false;
if (deinit) {
if (work->started)
wpa_s->connect_work = NULL;
@ -981,6 +983,11 @@ void sme_authenticate(struct wpa_supplicant *wpa_s,
return;
}
if (wpa_s->roam_in_progress) {
wpa_dbg(wpa_s, MSG_DEBUG,
"SME: Reject sme_authenticate() in favor of explicit roam request");
return;
}
if (radio_work_pending(wpa_s, "sme-connect")) {
/*
* The previous sme-connect work might no longer be valid due to