[PATCH] nl80211: Previous MAC isn't a foreign address

[Andrzej Ostruszka]

On 6/13/22 14:29, Michał Kazior wrote:
> On Mon, 13 Jun 2022 at 14:13, Andrzej Ostruszka <amo at semihalf.com> 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