Unable to connect to WPA2-Enterprise since 2.4-r1: WPA_ALG_PMK bug?
dcbw at redhat.com
Mon Apr 27 16:57:34 EDT 2015
On Mon, 2015-04-27 at 18:01 +0200, Ralf Ramsauer wrote:
> Hey Juoni, Dan,
> in the meanwhile I get more and more bug reports from people using the same WiFi
> I also tried another WPA2-Enterprise WiFi which uses TTLS/PAP instead of PEAP/MSCHAPv2 - same problem here.
> so here's what you need.
> These are affirmed affected cards:
> 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35) <- my own card / iwlwifi module
> 03:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
> 02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 33)
> 03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
> 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
> So this problem seems to be independent of the driver - the Atheros card definitely does not use the iwlwifi module.
> Dan, thanks to your tip, this saved me hours of manpage reading
> wpa_supplicant logs are attached. I only had to remove identity information.
> userA_wpa_supplicant_2_3 - http://pastebin.com/1P7Yfesn
> userA_wpa_supplicant_2_4 - http://pastebin.com/DmSUisrh
> userA_wpa_supplicant_diff - http://pastebin.com/Kiub8b7h
> userB_wpa_supplicant_2_4 - http://pastebin.com/y9TfwPx2
The 2.4 log messages here are harmless but probably shouldn't be showing
up, since they were only added to support PMK offload which your devices
1430145696.473416: wpa_driver_nl80211_set_key: ifindex=3 (wls3) alg=5 addr=(nil) key_idx=0 set_tx=0 seq_len=0 key_len=32
1430145696.473446: nl80211: Unexpected encryption algorithm 5
1430145696.473457: nl80211: KEY_DATA - hexdump(len=32): [REMOVED]
1430145696.473527: nl80211: set_key failed; err=-22 Invalid argument)
1430145696.473545: wls3: RSN: Cannot set PMK for key management offload
The real issue is this, in 2.4:
1430145696.473587: RSN: Added PMKSA cache entry for 54:78:1a:20:ff:4a network_ctx=0x17c9880
1430145696.473602: nl80211: Add PMKID for 54:78:1a:20:ff:4a
1430145696.473638: wls3: RSN: no PMKSA entry found - trigger full EAP authentication
1430145696.473687: wls3: RSN: Do not reply to msg 1/4 - requesting full EAP authentication
So, the PMKSA gets added to the cache in wpa_supplicant_get_pmk():
if (sm->proto == WPA_PROTO_RSN &&
sa = pmksa_cache_add(sm->pmksa,
(we know this because of "RSN: Added PMKSA cache entry for
But immediately after that in wpa_supplicant_get_pmk() the same PMKSA
fails to be found in the cache:
if (!sm->cur_pmksa && pmkid &&
pmksa_cache_get(sm->pmksa, src_addr, pmkid, NULL))
"RSN: the new PMK matches with the "
abort_cached = 0;
We know this because we don't see the "RSN: the new PMK matches with the
PMKID" in the logs for 2.4, and following the code flow we know that
sm->cur_pmksa == NULL and pmkid != NULL. This means that that the
PMKID sent by the authenticator (4c f5 81 c0 62 65 5c ec 16 e9 1c c7 73
c9 0e fb) does not match the one created by the supplicant in
pmksa_cache_add(), which causes the pmksa_cache_get() lookup to fail.
Thus abort_cached is still '1' and we see the log messages about "not
replying to 1 of 4, requesting full EAP authentication".
Up to Jouni, this is more complex than I can dig into right now...
> On 04/27/2015 03:34 PM, Jouni Malinen wrote:
> > On Mon, Apr 27, 2015 at 02:54:00PM +0200, Ralf Ramsauer wrote:
> >> After connecting to a WPA2-Enterprise network (wpa_supplicant 2.4-r1,
> >> PEAP/MSCHAPv2) I got the following messages in my journal (suspicious
> >> line highlighted):
> >> *Apr 27 13:45:49 lefay wpa_supplicant: nl80211: Unexpected
> >> encryption algorithm 5*
> > It looks like this gets printed even when the driver does not support
> > vendor extensions for configuring PMK for offloading operations. I guess
> > this could be cleaned up a bit by removing that call when the driver did
> > not indicate support for it. Anyway, this should not cause any
> > difference in behavior since the error from this operation is ignored.
> >> Apr 27 13:45:49 lefay NetworkManager: <info> (wlp3s0):
> >> supplicant interface state: associated -> 4-way handshake
> >> Apr 27 13:46:11 lefay NetworkManager: <warn> (wlp3s0):
> >> Activation: (wifi) association took too long
> > I would need to see more details on this to be able to determine what
> > happened. Can you run wpa_supplicant manually (i.e., without
> > NetworkManager) and add -dd on the command line?
> >> So 2.4-r1 seems to use a 4 way handshake, 2.2 uses a three way
> >> handshake? Why did it change?
> > I'm not sure what you are referring to with "three way handshake". There
> > has been no changes in the protocol design between those versions.
> >> So I recompiled wpa_supplicant 2.4-r1 with debugging symbols and started
> >> analyzing.
> >> The suspicious line "*nl80211: Unexpected encryption algorithm 5*" is
> >> thrown in driver_nl80211.c line 2399. It is a switch-case on the
> >> algorithm for WPA_ALG_PMK, which is ... not supported?
> >> Hum?
> > This is unlikely to be the main reason for the failure to complete
> > connection since the code path ends up trying to set a key which is
> > using unsupported algorithm. I'll remove this if the driver does not
> > indicate explicitly support for key management offload. Anyway, I don't
> > think that that change would fix the main issue here..
> > Which driver are you using?
> HostAP mailing list
> HostAP at lists.shmoo.com
More information about the HostAP