[PATCH 4/7] SME: Explicitly deauthenticate on authentication/association timeout

[Peer, Ilan]

Hi,

> -----Original Message-----
> From: Jouni Malinen <j at w1.fi>
> Sent: Sunday, 21 April 2024 12:02
> To: Otcheretianski, Andrei <andrei.otcheretianski at intel.com>
> Cc: hostap at lists.infradead.org; Peer, Ilan <ilan.peer at intel.com>
> Subject: Re: [PATCH 4/7] SME: Explicitly deauthenticate on
> authentication/association timeout
> 
> On Mon, Apr 08, 2024 at 04:06:58PM +0300, Andrei Otcheretianski wrote:
> > This would clear the local driver state and also the AP state, and
> > would allow clean connection establishment next time.
> >
> > This is needed in cases where the AP sends the association response
> > frame and sets the station state to associated, but the underlying
> > driver, e.g., mac80211, fails to parse the association response and
> > drops it, eventually clearing the association flow and sending a
> > timeout event to user space.
> 
> This seems to break the hwsim test case
> eht_mld_sae_two_links_disable_enable in my test setup. The RECONNECT
> command after having restarted the AP MLD seems to result in the Authentication
> frames not being received (no ACK) by the AP MLD. Those frames seem to be
> being sent to the old link addressed of the AP MLD and not the ones that were
> assigned when restarting it.
> 

Since the BSS table is not flushed in the wpa_supplicant, the BSS entries for the
initial AP MLD are still valid and thus the wpa_supplicant tries to use them for the
connection establishment. Flushing the BSS table before RECONNECT seems to
solve the issue.

This issue is there also before this change, however, with this change since the DEAUTH
event is injected to the wpa_supplicant, the network gets temporarily disabled and thus
the connection fails.

Sorry for the late response.

Regards,

Ilan.