wpa_supplicant key_mgmt=IEEE8021X issue

[Dan Williams]

On Mon, 2008-10-06 at 18:55 +0300, Jouni Malinen wrote:
> 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.

Some non-WPA-capable parts can certainly interpret IEs and pass those
along (which is quite useful) but can't actually connect with WPA.  Airo
comes to mind, but another case is prism54 (fullmac) where it can find
WPA IEs but can't handle CCMP encryption.  Same thing; the card reports
the AP capabilities correctly but obviously you have to ensure that the
AP's capabilities intersect with the card's.

Dan

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