On Mon, Feb 22, 2021 at 04:49:25PM -0800, Matthew Wang wrote:
> The roam D-Bus and wpa_cli commands flip the reassociate bit before
> calling wpa_supplicant_connect. wpa_supplicant connect eventually aborts
> ongoing scans, 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.
>
> Add a roam_in_progress flag to indicate that we're currently attempting
> to roam via D-Bus so that we don't initate another connection attempt.
> diff --git a/wpa_supplicant/ctrl_iface.c b/wpa_supplicant/ctrl_iface.c
> @@ -5686,6 +5686,15 @@ static int wpa_supplicant_ctrl_iface_roam(struct wpa_supplicant *wpa_s,
> + /*
> + * Indicate that an explicitly requested roam is in progress so scan
> + * results that come in before the 'sme-connect' radio work gets
> + * executed do not override the original connection attempt.
> + */
> + if (radio_work_pending(wpa_s, "sme-connect")) {
> + wpa_s->roam_in_progress = 1;
> + }
Is this limited to "sme-connect" on purpose or should "connect" be
included as well? I understand the only user of wpa_s->roam_in_progress
in this patch is in sme.c, but is that really the only issue that this
tries to address or could the same issue with ignoring an explicit roam
request apply to drivers that use internal SME instead of the
wpa_supplicant/sme.c implementation with split authentication and
association steps?
> diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c
> index c6cef5b1447..4fd0c5e104f 100644
> --- a/wpa_supplicant/sme.c
> +++ b/wpa_supplicant/sme.c
> @@ -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 = 0;
This is now the only place where this new variable is reset to 0. Is
that sufficient? What if the roam attempt fails for some reason before
being able to reach the authentication step? Could this flag be
forgotten in place and could that cause issues for the future completely
unrelated connection attempt?
> @@ -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;
> + }
I.e., how would this recover from sme_auth_start_cb() not getting called
after the last roam request?
> diff --git a/wpa_supplicant/wpa_supplicant_i.h b/wpa_supplicant/wpa_supplicant_i.h
> + int roam_in_progress; /* roam in progress */
The preferred type for new boolean variables is to use the C99 boolean
type through bool val = true/false.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
