On 6/13/22 14:29, Michał Kazior wrote:
On Mon, 13 Jun 2022 at 14:13, Andrzej Ostruszka <amo@xxxxxxxxxxxx> wrote:
When using MAC randomization suppliant can change local MAC address
during roaming scenario:
[...]
This sounds to me like it's not necessarily an issue related to
randomized addresses. With the patch it's still possible to suffer
packet loss of the AP->STA deauth which would fail to clear the flag
leading to the same kind of issue.
This is not AP->STA deauth that is being ignored, it is our own one.
The scenario is more or less like this call flow:
wpa_supplicant_deauthenticate <===== (supplicant wants deauth)
wpa_drv_deauthenticate <===== (calls driver deauth)
wpa_driver_nl80211_mlme(NL80211_CMD_DEAUTHENTICATE)
ignore_next_local_deauth = drv_associated && "no driver error"
wpa_supplicant_event(EVENT_DEAUTH) <===== (signals event)
Note that we handle/signal this event right away (last line). That is
the reason why we mark this flag, cause now we expect to see the same
deauth being "announced" by the driver over netlink socket that we are
subscribed to. When it comes then we will clear the flag in the
relevant callback.
However with randomization we don't even get to the callback, since we
are being filtered out by the address checks which conclude that MAC1 is
a "foreign" address (we've changed to MAC2 due to randomization) and
drops the message.
Just for the background information, concrete scenario where this has
been observed is the ChromeOS wifi.MARSSIDRoam test. In there we
connect to AP1 then force roam to AP2 and then shutdown AP2 and expect
DUT to roam back to AP1. With randomization turned on we end up at AP2
with flag set. When shutting down AP2 it broadcasts Deauthentication
and we observe basically two behaviours:
- either this is reported by the driver as a broadcast and supplicant
says "Was expecting local deauth but got another ..." and proceeds
with handling of it or
- it is reported as a "locally generated" (either driver misses the
message and generates it based on lost beacon, or there is some error
in driver) and in that case supplicant says "Ignore deauth event
triggered due to own deauth" and nothing happens which causes test to
fail waiting for the DUT to roam back to AP1.
I hope that clarifies. If not, please let me know.
With regards
Andrzej
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
