Hello gurus, maybe someone seen the strange issue with sudden clients deauth I'm experiencing randomly (~20-30 times per day from different devices(mostly laptops) ) on the vWLC? Details are below:
## Environment
- Controller: Catalyst 9800-CL (virtual), IOS-XE 26.1.2, with APSP1 (CSCwv96200 / CSCwv93265) installed
- AP model: AIR-AP2802I-B-K9 (4× APs, FlexConnect local switching)
- Affected WLAN security: WPA2+WPA3 transition (PSK+SAE, FT enabled), **PMF mandatory**
- Also reproduced on a second WLAN: WPA3-only (SAE, FT), **PMF mandatory**
- Affected clients: multiple Windows laptops with Intel Wi-Fi chipsets (confirmed via MAC OUI — Intel Corporate), occurring far less frequently on Android/iOS clients on the same SSIDs
- Client exclusion/Device Analytics (`device-analytics`/`pc-analytics` WLAN config) was disabled on both affected WLANs as a test — **the bug still occurs after this change**, ruling it out as the trigger
## Symptom
Clients are intermittently kicked with:
```
Delete reason: 69, CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE
```
The client typically reconnects on its own within seconds, but the disruption is visible to end users (brief connectivity drop, sometimes requiring the user to manually reconnect).
## Root cause found via Conditional Debug / Radioactive Tracing
Scoping `debug platform condition feature wireless mac <mac>` to the affected clients and capturing `show logging profile wireless internal` at DEBUG level on `dot11`, `dot11-frame`, `dot11-validate`, `capwapdata-decap`, `client-auth`, `client-orch-sm` reveals the exact failure point, reproduced identically on multiple different Intel-chipset laptops:
```
{wncd_x_R0-0}{1}: [client-orch-sm]: Ewlc dot11 packet handler. Received Disassociation Request
{wncd_x_R0-0}{1}: [dot11-validate] (debug): Validate dot11 ie for samsung payloads. Invalid ie type
Received ouiType 1 Expected ouiType 34
Received oui 0x0, 0x17, 0x35, Expected oui 0x0, 0x0, 0xf0
{wncd_x_R0-0}{1}: [dot11]: Deauth/Disassoc: Failed to get tlv element, only 8 bytes available
{wncd_x_R0-0}{1}: [dot11] (ERR): Failed to parse disassoc/deauth payload, continuing
{wncd_x_R0-0}{1}: [dot11]: Dot11 send delete to co. Delete reason: 69, CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE.
```
**Analysis:** there is no decision/dispatch step in the trace between "Received Disassociation Request" and the samsung-payload validation call — it runs unconditionally on every disassoc/deauth frame. `0x0, 0x17, 0x35` is a genuine, registered Intel OUI ("Intel Wireless Network Group") — confirmed this is the client's own real vendor-specific information element (Element ID 221/0xdd), not malformed or spoofed data. The validator appears to assume any vendor-specific IE present in this position of the frame must be Samsung's proprietary format (expected OUI `00:00:f0`, the registered Samsung OUI), and when it isn't, the resulting mismatch corrupts the rest of the TLV parse ("only 8 bytes available") instead of gracefully skipping the unrecognized vendor IE. The malformed-parse result is then treated as a timeout/failure condition and the client is deleted.
This appears tied to the (undocumented, non-configurable) mechanism described in Cisco Live session BRKEWN-2926, where Samsung Galaxy S10+/Android 9+ devices proactively send an unsolicited vendor-specific action frame with device/OS info when they detect a Cisco AP — used internally by WLC/Catalyst Center/Meraki. This does not appear to be gated by the configurable `device-analytics`/`pc-analytics` WLAN knob (added in 17.6.x for Intel PC telemetry) — disabling that config entirely did not stop the issue from recurring.
## Prior art (same exact signature, different client/platform/year)
Found one earlier community thread with the identical trace signature, on an unrelated platform:
https://community.cisco.com/t5/wireless/cisco-c9800-l-f-k9-and-iphone-12-reconnection/td-p/4412379
(C9800-L-F-K9 + AIR-AP1815I, iPhone 12 client, ~2021). In that case the outcome was different — `Dropping the disassoc or deauth request. 11w not enabled` — i.e. the controller safely discarded the malformed frame instead of deleting the client. **This strongly suggests the underlying parse bug is not new and not fixed**, but its consequence depends entirely on whether PMF (802.11w) is mandatory: without PMF, the broken parse is silently dropped; with PMF mandatory (required for WPA3/SAE in our deployment), the controller proceeds to delete the client based on the corrupted parse result.
## What I've ruled out
- `device-analytics`/`pc-analytics` WLAN config — disabled entirely on both affected SSIDs, bug recurred afterward with byte-identical signature.
- `ignore-rsn-ie-len` WLAN command — unrelated (governs RSN IE length validation during 4-way key exchange, a different IE type/frame context).
- CSCwv96200/CSCwv93265 (APSP1, already installed) — confirmed via the bug's own record this addresses downstream 802.11 action frame visibility (OpenRoaming/11k/11v/11r), unrelated to disassoc/deauth parsing.
## Questions
1. Is there an existing bug ID (CSCwxxxxxxx) tracking this specific "samsung payloads" validator mis-handling non-Samsung vendor IEs in disassoc/deauth frames?
2. Is there any config-level workaround to make the validator skip-and-continue instead of corrupting the parse, short of disabling PMF (which isn't acceptable in our deployment due to other WPA3/RSNXE-related workarounds already in place)?
3. Has this been fixed in any later train (17.12.x / 17.15.x / 17.18.x) in a way that wouldn't show up as a public release note (e.g. folded into a general IE-parsing hardening fix)?
Happy to share the full radioactive trace captures if useful for triage and I have NO Samsung devices in the network (except one TV which apparently doesn't experience the problem)
