wpa_supplicant key_mgmt=IEEE8021X issue

Jouni Malinen j at w1.fi
Mon Oct 6 11:55:58 EDT 2008


On Mon, Oct 06, 2008 at 06:28:07PM +0300, Andriy Tkachuk wrote:

> I noticed that when key_mgmt=IEEE8021X wpa_supplicant tries to connect
> to WPA enabled APs, for example:
> 
> 1223306606.324317: 2: 00:14:c2:a4:1b:e2 ssid='WLAN4TEST' wpa_ie_len=24 rsn_ie_len=20 caps=0x10
> 1223306606.324336:    selected non-WPA AP 00:14:c2:a4:1b:e2 ssid='WLAN4TEST'

Hmm.. My first thought was that this should not really happen, but after
a bit more thorough attempt at remembering why this ended up being the
case, I think this is actually by design..

Non-WPA clients would not know about WPA/RSN IE and as such, they would
attempt to associate even if the WPA/RSN IE is included Beacon/Probe
Response frames. As such, wpa_supplicant ignores WPA/RSN IE when WPA
mode is not enabled and allows (non-WPA) IEEE 802.1X to attempt using
the AP.

> It looks like following patch fixes the issue:

It would likely make wpa_supplicant behave the way you expected it to
behave here. However, I'm not sure whether it would really be a fix in
every case since it might break connection that was working previously
(i.e., a client that does not know how to use WPA and AP that supports
both WPA and non-WPA IEEE 802.1X). Consequently, I'm a bit hesitant on
applying this patch. It would probably be fine for a case where the
driver can be shown to understand WPA (driver capabilities indicate
this). In that case, it sounds relatively safe to skip the network if
IEEE 802.1X is configured (however, even that could break a potentially
useful case of being able to test such an AP that has backwards
compatibility support if one is using a WPA-enabled client driver).

-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list