Re: [PATCH] wifi: mac80211: defer AP-side FT key upload until association

Hi James,

> Another case I forgot to mention is the client will FT roam and
> immediately start dropping _ALL_ IP traffic (despite the 802.11 layer
> remaining connected/stable). We've seen this with several vendors and
> actually had to create a watchdog to monitor for this situation and force
> a deauth on the client side. I wonder if this is closer to the issue here.

Yes, that is much closer to the failure mode I would expect here. The FT
reassociation can complete because the initial set_key() failure is not
propagated as an association failure. After calling the void
wpa_ft_install_ptk() helper on WPA_ASSOC_FT, the caller unconditionally sets
sm->ft_completed = 1; there is no success value to check. If that retry also
fails, the AP and station can remain associated at the 802.11 state-machine
level while the AP has no usable PTK, leaving the protected data path
inoperable until a disconnect and reassociation.

That does not establish that the vendor APs you observed hit this exact
mac80211 ASSOC gate; a different key/peer ordering bug, or another data-path
problem, could produce the same symptom. For this specific race, the strongest
signature would be a successful FT reassociation followed by no working
protected data, together with a failed pre-association key installation and a
failed or absent post-association retry on the AP.

Even without useful AP logs, a station-side monitor capture covering the FT
exchange through the watchdog-triggered deauthentication could help narrow
this down. In particular, protected data continuing to be transmitted and
acknowledged at the 802.11 layer without any higher-layer response would be
consistent with a key/data-path failure on the AP.

Thanks,
Andrea