can't get wpasupplicant to authenticate against router using wpa-psk

[Brian Bender]

Jason, I'm working on a vendor-supplied proprietary driver  
[disclaimer: not using hostap] for an embedded product, and I see  
something in your logs (selectively snipped to point it out) that is  
similar to a situation I'm currently fighting with.

On Feb 14, 2006, at 10:38 PM, Jason Carr wrote:

> Feb 14 21:58:52.374089: Selecting BSS from priority group 0
> Feb 14 21:58:52.374105: 0: 00:13:10:68:b7:d2 ssid='flacid.org'
> wpa_ie_len=30 rsn_ie_len=26 caps=0x11
                              ^^^^^^^^^^
> Feb 14 21:58:52.374126:    selected based on RSN IE
> Feb 14 21:58:52.374145: Trying to associate with 00:13:10:68:b7:d2
> (SSID='flacid.org' freq=0 MHz)
> Feb 14 21:58:52.374162: CTRL_IFACE monitor send - hexdump(len=23):  
> 2f 74
> 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 32 39 37 32 2d 30 00 00 00
> Feb 14 21:58:52.374194: Cancelling scan request
> Feb 14 21:58:52.374211: WPA: clearing own WPA/RSN IE
> Feb 14 21:58:52.374226: Automatic auth_alg selection: 0x1
> Feb 14 21:58:52.374246: RSN: using IEEE 802.11i/D9.0
> Feb 14 21:58:52.374261: WPA: Selected cipher suites: group 8  
> pairwise 24
> key_mgmt 1
> Feb 14 21:58:52.374277: WPA: set AP WPA IE - hexdump(len=30): dd 1c 00
> 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00  
> 50 f2
> 01 01 00
> Feb 14 21:58:52.374302: WPA: set AP RSN IE - hexdump(len=26): 30 18 01
> 00 00 0f ac 02 02 00 00 0f ac 04 00 0f ac 02 01 00 00 0f ac 01 01 00
> Feb 14 21:58:52.374326: WPA: using GTK TKIP
> Feb 14 21:58:52.374342: WPA: using PTK CCMP
> Feb 14 21:58:52.374358: WPA: using KEY_MGMT 802.1X
> Feb 14 21:58:52.374373: WPA: Set own WPA IE default - hexdump(len=22):
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 30 14 01 00 00 0f ac 02 01 00 00 0f ac 04 01 00 00 0f ac 01 00 00
<snip>
> Feb 14 21:58:53.358609: Wireless event: cmd=0x8b15 len=20
> Feb 14 21:58:53.358654: Wireless event: new AP: 00:00:00:00:00:00
> Feb 14 21:58:53.358674: Setting scan request: 0 sec 100000 usec
> Feb 14 21:58:53.358695: BSSID 00:13:10:68:b7:d2 blacklist count
> incremented to 2
> Feb 14 21:58:53.358712: State: ASSOCIATED -> DISCONNECTED
<snip>

With newer Cisco APs (yours looks to be a Cisco-Linksys, so I assume  
it's a Linksys after the Cisco buyout?), they've started including  
the "RSN capabilities" field in the WPA_IE. The WPA_IE in the  
association request needs to match the one in the 3/4 key message in  
the 802.1X 4-way handshake, where you've selected the features you're  
going to use. Notice the line that says "Set own WPA IE default -  
hexdump(len=22)"? That doesn't have the rsn caps element in it. See  
my question below as to why I think that's important. As to the "used  
to work, now it doesn't, was the firmware on that AP by any chance  
updated from a version that was merely WPA-capable to one that was  
802.11i-capable? I have one 1200-series Cisco AP that only does WPA,  
and it only sends/requires the len==22 version of the WPA_IE, while  
the newer ones we have use the longer one, so it seems that they  
changed at some point, and it probably has something to do with code  
reuse between WPA and WPA2 cases. *shrug*

Question for the group: from what I can tell in testing, I'm not able  
to authenticate with the newer Cisco APs _unless_ I include that RSN  
Caps element in my WPA_IEs. It seems that even if my WPA_IE's match  
like they're supposed to (that was an earlier bug I had to fix <g>),  
if they're the len==22 variety, with no RSN Caps field, the AP  
disassociates me immediately after the 4-way handshake.

The WPA spec is a little vague; it says that "Clause 7.3.2.25.3?RSN  
Capabilities, the GTKSA and PTKSA Replay counter flags are not used  
in WPA." (incidentally, Cisco _is_ sending data in those flags within  
the capabilities field, so in that sense, they look like they're  
slightly wrong in their implementation) It doesn't address, though,  
whether that whole field is absolutely required. Their sample code  
illustrates conditionally looking for successive elements in the  
variable IEs based on IELen; I'd expect that the APs _should_ be able  
to tell from the length that that RSN Caps field isn't there, and the  
IE is still technically valid for a WPA session. At least I think so. :)

Has anyone else run into this situation?

Thanks,

Brian

-- 
Brian Bender
Principal Software Engineer
Vocollect, Inc.
Pittsburgh, PA, USA
[Apologies for the following "disclaimer" -- it's corporate policy.]

-CONFIDENTIAL, PRIVILEGED COMMUNICATION-
This e-mail transmission is private and intended for the addressee(s)  
only.  It may contain information that is privileged and/or  
confidential.  If you have received this transmission in error, you  
are not authorized to read, copy, disclose or disseminate it in any  
manner. If you have received it in error, please delete it and all  
copies (including backup copies) that have been made, and transmit a  
reply message informing the sender that it was misdirected.