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

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

[andcov23]

From: Andrea Covelli <andcov23@gmail.com>

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")
Cc: stable@vger.kernel.org
Link: https://github.com/openwrt/openwrt/pull/23181
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Andrea Covelli <andcov23@gmail.com>
---
A backport of this change was tested with mt76 on Cudy WR3000E v1 and
WR3000P v1 devices running OpenWrt 25.12.5. Repeated bidirectional
802.11r FT roams completed without new "key addition failed" messages.

 net/mac80211/cfg.c      | 18 +++++++++++++++---
 net/mac80211/key.c      | 27 +++++++++++++++++++++++++++
 net/mac80211/key.h      |  4 ++++
 net/mac80211/sta_info.c |  1 +
 4 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 0a9247be26af..a95435b720a9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -666,7 +666,14 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct wireless_dev *wdev,
 		key->conf.flags |= IEEE80211_KEY_FLAG_NO_AUTO_TX;
 
 	if (mac_addr) {
+		bool defer_hw_upload;
+
 		sta = sta_info_get_bss(sdata, mac_addr);
+		defer_hw_upload =
+			sta && pairwise && !sta->sta.epp_peer &&
+			!test_sta_flag(sta, WLAN_STA_ASSOC) &&
+			(sdata->vif.type == NL80211_IFTYPE_AP ||
+			 sdata->vif.type == NL80211_IFTYPE_AP_VLAN);
 		/*
 		 * The ASSOC test makes sure the driver is ready to
 		 * receive the key. When wpa_supplicant has roamed
@@ -681,14 +688,19 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct wireless_dev *wdev,
 		 * If (re)association frame encryption support is not present,
 		 * cfg80211 will not allow key installation in non‑AP STA mode.
 		 *
-		 * TODO: accept the key if we have a station entry and
-		 *	 add it to the device after the station associates.
+		 * AP-side FT may also install a pairwise key before the
+		 * station is associated. Keep it in mac80211 and upload it
+		 * to the driver after the station reaches ASSOC.
 		 */
 		if (!sta || (!sta->sta.epp_peer &&
-			     !test_sta_flag(sta, WLAN_STA_ASSOC))) {
+			     !test_sta_flag(sta, WLAN_STA_ASSOC) &&
+			     !defer_hw_upload)) {
 			ieee80211_key_free_unused(key);
 			return -ENOENT;
 		}
+
+		if (defer_hw_upload)
+			key->flags |= KEY_FLAG_DEFERRED_HW_UPLOAD;
 	}
 
 	switch (sdata->vif.type) {
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index f45e792abede..180e2aa9649e 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -144,6 +144,11 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
 		return -EINVAL;
 	}
 
+	if (key->flags & KEY_FLAG_DEFERRED_HW_UPLOAD) {
+		ret = 1;
+		goto out_unsupported;
+	}
+
 	if (!key->local->ops->set_key)
 		goto out_unsupported;
 
@@ -997,6 +1002,28 @@ void ieee80211_reenable_keys(struct ieee80211_sub_if_data *sdata)
 	}
 }
 
+void ieee80211_upload_deferred_sta_keys(struct sta_info *sta)
+{
+	struct ieee80211_local *local = sta->local;
+	struct ieee80211_key *key;
+	int i, ret;
+
+	lockdep_assert_wiphy(local->hw.wiphy);
+
+	for (i = 0; i < ARRAY_SIZE(sta->ptk); i++) {
+		key = wiphy_dereference(local->hw.wiphy, sta->ptk[i]);
+		if (!key || !(key->flags & KEY_FLAG_DEFERRED_HW_UPLOAD))
+			continue;
+
+		key->flags &= ~KEY_FLAG_DEFERRED_HW_UPLOAD;
+		ret = ieee80211_key_enable_hw_accel(key);
+		if (ret)
+			sdata_err(key->sdata,
+				  "failed to enable deferred key (%d, %pM): %d\n",
+				  key->conf.keyidx, sta->sta.addr, ret);
+	}
+}
+
 static void
 ieee80211_key_iter(struct ieee80211_hw *hw,
 		   struct ieee80211_vif *vif,
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 826e4e9387c5..97d3bbcf0ac2 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -32,10 +32,13 @@ struct sta_info;
  * @KEY_FLAG_UPLOADED_TO_HARDWARE: Indicates that this key is present
  *	in the hardware for TX crypto hardware acceleration.
  * @KEY_FLAG_TAINTED: Key is tainted and packets should be dropped.
+ * @KEY_FLAG_DEFERRED_HW_UPLOAD: Key upload is deferred until the station
+ *	is associated.
  */
 enum ieee80211_internal_key_flags {
 	KEY_FLAG_UPLOADED_TO_HARDWARE	= BIT(0),
 	KEY_FLAG_TAINTED		= BIT(1),
+	KEY_FLAG_DEFERRED_HW_UPLOAD	= BIT(2),
 };
 
 enum ieee80211_internal_tkip_state {
@@ -165,6 +168,7 @@ void ieee80211_free_keys(struct ieee80211_sub_if_data *sdata,
 			 bool force_synchronize);
 void ieee80211_free_sta_keys(struct ieee80211_local *local,
 			     struct sta_info *sta);
+void ieee80211_upload_deferred_sta_keys(struct sta_info *sta);
 void ieee80211_reenable_keys(struct ieee80211_sub_if_data *sdata);
 int ieee80211_key_switch_links(struct ieee80211_sub_if_data *sdata,
 			       unsigned long del_links_mask,
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index d12aed9c1756..625f628b46a0 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1468,6 +1468,7 @@ static int _sta_info_move_state(struct sta_info *sta,
 	case IEEE80211_STA_ASSOC:
 		if (sta->sta_state == IEEE80211_STA_AUTH) {
 			set_bit(WLAN_STA_ASSOC, &sta->_flags);
+			ieee80211_upload_deferred_sta_keys(sta);
 			sta->assoc_at = ktime_get_boottime_ns();
 			if (recalc) {
 				ieee80211_recalc_min_chandef(sta->sdata, -1);
-- 
2.53.0

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

[Johannes Berg]

On Thu, 2026-07-30 at 18:14 +0200, andcov23@gmail.com wrote:
> From: Andrea Covelli <andcov23@gmail.com>
> 
> 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: stable@vger.kernel.org

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

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

[Andrea Covelli]

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 <johannes@sipsolutions.net> wrote:
>
> On Thu, 2026-07-30 at 18:14 +0200, andcov23@gmail.com wrote:
> > From: Andrea Covelli <andcov23@gmail.com>
> >
> > 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: stable@vger.kernel.org
>
> 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

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

[Johannes Berg]

Hi Andrea,

> 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.

I think I'd mostly like to understand how it interacts. SMD Transition
won't actually handle this particular path, but client-side has a
similar issue where the key is available before the STA entry for the AP
is fully available.

Now looking at the code I also wonder devices could just deal with the
key installed before the station is marked associated?

johannes

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

[Andrea Covelli]

Hi Johannes,

> I think I'd mostly like to understand how it interacts. SMD Transition
> won't actually handle this particular path, but client-side has a similar
> issue where the key is available before the STA entry for the AP is fully
> available.

I compared this with your posted group-key RFC. Its SMD-specific GTK/CIGTK
slots are separate from this pairwise PTK path, but the generic key-slot
refactoring also covers sta->ptk[] and moves the ASSOC gate. This AP-side
mechanism requires an existing, lookupable sta_info and a PTK slot, so it
cannot represent a key arriving before that point or handle the earlier
client-side phase as-is. The deferred flag can still live on the individual
ieee80211_key after rebasing. With the new tailroom handling, the ASSOC-time
retry would call ieee80211_key_enable_hw_accel(key, true), since it is
updating an already-linked key and must adjust tailroom accounting after a
successful hardware upload.

> Now looking at the code I also wonder devices could just deal with the key
> installed before the station is marked associated?

mt7915's set_key() currently returns -EOPNOTSUPP until its AUTH-to-ASSOC setup
marks the WCID ready, while wlcore allocates its per-peer firmware HLID during
that transition. Outside the EPP-specific
NL80211_EXT_FEATURE_ASSOC_FRAME_ENCRYPTION opt-in, I could not find a mac80211
capability that guarantees early set_key() is safe for an ordinary AP-side FT
PTK, so I did not assume that every driver can be called early.

The OpenWrt PR also provides a useful A/B result for the
SW_CRYPTO_CONTROL interaction. The initial revision deferred the key with
ret left as -EOPNOTSUPP. It removed the error on mt76, but the error remained
on EAP1200H and OnHub, whose standard OpenWrt profiles use ath10k-ct. A
follow-up moved the deferred branch ahead of the sta->uploaded check and set
ret = 1. The subsequent report for the same device set showed the error gone:

https://github.com/openwrt/openwrt/pull/23181#issuecomment-4500287395

The revised path removed the reported error on those configurations. This is
consistent with synthesizing ret = 1 having permitted software crypto, but it
does not show whether ath10k accepts set_key() before ASSOC, because the
callback was skipped, or whether the key was later uploaded to hardware. It
also illustrates precisely the SW_CRYPTO_CONTROL issue you raised: only an
actual return value of 1 from the driver authorizes software crypto. I do not
want mac80211 to synthesize that permission.

For an upstream solution, would you prefer a genuine dormant-key state, where
the key is neither uploaded nor authorized for software use until ASSOC and
upload failure has a defined path, or should affected drivers handle the early
key themselves, either by installing it immediately or caching it until their
peer setup completes? The latter could use an explicit capability so mac80211
relaxes the ASSOC gate only for drivers supporting that ordering. For a
SW_CRYPTO_CONTROL driver that cannot install or cache the key early, an
explicit return value of 1 followed by a mac80211 retry at ASSOC is another
possible contract. I would avoid adding that, however, and understood your
question as suggesting that driver-side handling should be investigated first.

I have kept v2 local while clarifying this direction and dropped the stable
CC as suggested.

Best,
Andrea

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

[Andrea Covelli]

Hi Johannes,

Just a gentle ping on my August 4 reply when you have a chance. Is
driver-side handling of the early key the direction you would prefer me to
investigate first?

Thanks,
Andrea

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

[James Prestwood]

Hi Andrea,

On 7/30/26 9:14 AM, andcov23@gmail.com wrote:
> From: Andrea Covelli <andcov23@gmail.com>
>
> 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.

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.

Thanks,

James

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

[Andrea Covelli]

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

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

[James Prestwood]

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

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

[Andrea Covelli]

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.

Thanks,
Andrea

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

[James Prestwood]

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