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

[Andrea Covelli <andcov23@gmail.com>]

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.

Thanks,
Andrea