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

Hi Johannes,

Thanks for the review. Understood, I’ll hold the standalone patch and wait
for the SMD-transition series. I’ll review how it handles the deferred-key
and SW_CRYPTO_CONTROL paths and test it against the AP-side FT case on mt76.

Best,
Andrea


On Thu, Jul 30, 2026 at 6:21 PM Johannes Berg <[email protected]> wrote:
>
> 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