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

[James Prestwood <prestwoj@gmail.com>]

Hi Andrea,

On 8/11/26 11:25 AM, Andrea Covelli wrote:
> 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.

This is great to hear. Getting a monitor capture is tricky since its not 
a consistent problem, but I will try and get this either way.

I really appreciate the context here, we've been struggling with this 
issue for years with no help from vendors. This is the biggest break 
I've gotten.

Thanks,

James

>
> Thanks,
> Andrea