wpa_supplicant 2.12-1: WPA2-Enterprise EAP-TLS fails at 4-way handshake, 2.11 works

[Jouni Malinen]

On Sun, Aug 23, 2026 at 06:27:33PM +0530, Anil Kumar wrote:
> I am experiencing what appears to be a regression in wpa_supplicant
> 2.12-1 compared to 2.11-5 on a WPA2-Enterprise / IEEE 802.1X network
> using EAP-TLS.

> Relevant log:
> 
>     WPA: Sending EAPOL-Key 2/4
>     WPA: Send EAPOL-Key frame to <AP> ver=2 mic_len=16 key_mgmt=0x1
>     WPA: EAPOL-Key MIC using HMAC-SHA1
>     WPA: Derived Key MIC - hexdump(len=16): [redacted]
>     WPA: TX EAPOL-Key - hexdump(len=125): ...
>     nl80211: Send over control port dest=<AP> proto=0x888e len=125 no_encrypt=1
>     nl80211: tx_control_port cookie=...
>     nl80211: Control port TX status (ack=1)
> 
> No EAPOL-Key 3/4 is received after this.

Would you be able to share the full debug log for the connection
attempt? Sending it privately would be fine if you want to avoid public
disclosure of the details.
> 
> About two seconds later the station is removed/deauthenticated:
> 
>     kernel: wlan0: deauthenticated from <AP> (Reason: 3=DEAUTH_LEAVING)
>     nl80211: NL80211_CMD_DEL_STATION received
>     nl80211: Delete station <AP>
>     nl80211: NL80211_CMD_DEAUTHENTICATE received
>     wlan0: CTRL-EVENT-DISCONNECTED ... reason=3

This would likely imply that the EAPOL-Key msg 2/4 was not accepted by
the AP for some reason.

> I also see:
> 
>     nl80211: _cmd_set_pmksa failed: -95 (Operation not supported)
> 
> The supplicant nevertheless continues into the 4-way handshake after
> this, so I am not certain whether the PMKSA error is related.

That should not make a difference for this.

> I recently noticed upstream commit:
> 
>     7c1e798198f34e35a9a1d40c05e0ae34a595cd62
> 
>     "wpa_supplicant: Fix PMKSA caching with 802.1X 4-way handshake offload"
> 
> The commit specifically concerns driver-based 4-way handshake offload
> with IEEE 802.1X and PMK handling. Since my failure occurs immediately
> after successful 802.1X authentication and during the 4-way handshake,
> I wondered whether this could be related to the same code path.
>
> I am not certain that this commit is the fix for my issue, but the
> similarity seemed significant enough to report.

That change is not applicable for iwlwifi, so it should not really be
relevant even when this particular function gets called.

-- 
Jouni Malinen                                            PGP id EFC895FA