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

Hi Andrea,

On 8/11/26 10:35 AM, Andrea Covelli wrote:
> Hi James,
>
>> How does this present itself on the station when this happens? I'm
>> curious because over the years I've seen strange behavior from basically
>> all vendors of access points like:
>>
>> - Mysterious association timeouts despite good RSSI/utilization.
>> - Denied FT associations with reason code 53
>> - Successful FT roams immediately followed by a deauth with reason code
>> 6, 7, or 9.
>>
>> I know the above could be from any host of issues, but I'm mostly
>> curious what the client sees with this specific FT key upload failure.
> The common case appears to be that the station sees a successful FT roam. In
> hostapd, wpa_ft_install_ptk() simply returns if its pre-association
> wpa_auth_set_key() call fails. Since wpa_ft_install_ptk() returns void, that
> failure is not converted into an association status code. On the subsequent
> WPA_ASSOC_FT event, hostapd calls wpa_ft_install_ptk(sm, 1) and retries after
> association. If that retry succeeds, the only visible symptom is the AP-side
> nl80211 error.
>
> The OpenWrt field reports reflect both outcomes. Most occurrences were
> described as log-only, consistent with the retry succeeding. Post-patch tests
> recorded successful FT associations without the AP-side error. I did not,
> however, collect a station-side debug log or packet capture for the unpatched
> case.
>
> There is one more severe report from a three-AP mt7981 deployment. The
> reporter correlated clusters of this error with Android and iPhone connectivity
> loss. One AP log showed 14 key-addition failures, about three minutes without
> the client, and then an eventual successful association with auth_alg=ft:
>
> https://github.com/openwrt/mt76/issues/1098
>
> After applying the OpenWrt patch, the same reporter observed several days
> with no key-addition errors and normal roaming. This is useful operational
> evidence, but it still lacks a synchronized station trace, so I cannot tie
> this path to a specific status or reason code. The initial pre-association
> set_key() failure alone should not produce an association timeout or status
> 53. Of the cases you listed, a successful FT roam followed by connectivity
> loss is structurally the closest match if the post-association retry also
> fails and leaves the AP without the PTK. I cannot currently connect that to
> reason 6, 7, or 9, though; the station-visible sequence needs a capture to
> determine.
>
> A synchronized station debug log or packet capture and AP log around one of
> the cases you have seen would be very useful for determining whether it is
> this race.

I unfortunately can't get AP logs beyond what the vendor exposes (and 
they aren't useful). 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.

Thanks,

James

>
> Thanks,
> Andrea