Re: [PATCH] wifi: mac80211: defer AP-side FT key upload until association
Johannes Berg <[email protected]> Thu, 30 Jul 2026 18:21:19 +0200
| Newsgroups | org.kernel.vger.linux-wireless |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 2026-07-30 at 18:14 +0200, [email protected] wrote: > From: Andrea Covelli <[email protected]> > > During an AP-side Fast Transition, hostapd may install the PTK after > creating a station entry but before marking it associated. The ASSOC gate > in ieee80211_add_key() rejects the request with -ENOENT, producing: > > nl80211: kernel reports: key addition failed > > Userspace may retry after association, but this race can instead break > the roam, particularly with PMF. > > Accept pre-association pairwise keys on AP and AP_VLAN interfaces once > the station exists. Mark only those keys as deferred so hardware upload > is skipped while the key is stored in mac80211. Upload the marked PTKs > after the driver's AUTH-to-ASSOC state transition succeeds. > > Track deferred state on each key and scan the station's PTK slots at > ASSOC so hardware upload is limited to keys accepted before association. > EPP peers are excluded from this deferral because EPP requires the PTK > to be available before association to encrypt and decrypt > (Re)Association Request and Response frames. > > Fixes: 1626e0fa740d ("mac80211: fix FT roaming") This is _ages_ ago, so this bug has been around basically forever. > Cc: [email protected] I don't think the stable thing is appropriate then. I also have a very large set of changes in this area that actually end up doing something very similar for SMD Transition, and much more comprehensively, which I'm about to post, so I think it's better for this to be integrated with that work later. This also doesn't consider the case of failure on HW support, i.e. with SW_CRYPTO_CONTROL it just (without any comment I might add) skips the thing by pretending the driver said it was OK. Not convinced that's a good idea, although this might be something that can't really solved better, perhaps. johannes