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

Wed Feb 15 12:33:04 PST 2006

In both cases, though, (I'm just looking at code here, not actually  
running it, so if I'm way off base, just tell me to shut up), if I'm  
reading your debug logs right I think it uses wpa_gen_wpa_ie_wpa() to  
generate the WPA IE to use to authenticate, which explicitly does not  
include the capabilities field -- after it sets the key management  
choice, there's the comment "/* WPA Capabilities; use defaults, so no  
need to include it */".

 From what I can tell from trying to debug my driver (again, I'm not  
100% certain, but it's my current picture of things), the Cisco AP's  
seem to reject otherwise valid 802.1X WPA authentication if you don't  
_explicitly_ have that capabilities field present in the WPA_IE.

I'm looking at wpa_supplicant-0.5.1. Just for the fun of it, can you  
try this patch and see if it makes a difference?

=========== cut ============

--- wpa.c~	2006-01-29 21:25:10.000000000 -0500
+++ wpa.c	2006-02-15 15:07:45.000000000 -0500
@@ -588,6 +588,9 @@
	pos += WPA_SELECTOR_LEN;
	/* WPA Capabilities; use defaults, so no need to include it */
+	/* Er, except for the newer Cisco APs that seem to insist on seeing  
it */
+	*pos++ = 0;
+	*pos++ = 0;
	hdr->len = (pos - wpa_ie) - 2;
=========== cut ============

(BTW, I scrounged up a spare 2.5" drive, and I'm installing Slackware  
on a work-supplied Thinkpad to try this out myself. I need a good  
datapoint besides just a bunch of closed-source Windows drivers. :)

  - Brian

On Feb 15, 2006, at 1:10 PM, Jason Carr wrote:

> Hello Pittsburgh Friend ;)
>
> The access point is actually a hacked WRT54G v4 running OpenWRT.  I
> haven't rebooted it since I installed OpenWRT, so I haven't changed
> anything on that device.
>
> The similarities are that both devices are Cisco or Linksys.  We use
> Cisco 1220's and 1240's, although the one I would have been connecting
> to is the 1220.
>
> Here's from the Cisco AP:
>
> Feb 15 13:03:32.481390: Scan SSID - hexdump_ascii(len=7):
>      43 4d 55 2d 57 50 41                              CMU-WPA
> Feb 15 13:03:35.481848: Scan timeout - try to get results
> Feb 15 13:03:35.482088: Received 2896 bytes of scan results (13 BSSes)
> Feb 15 13:03:35.482104: Scan results: 13
> Feb 15 13:03:35.482118: Selecting BSS from priority group 0
> Feb 15 13:03:35.482131: 0: aa:bb:cc:dd:ee:ff ssid='CMU-WPA'
> wpa_ie_len=26 rsn_ie_len=22 caps=0x11
> Feb 15 13:03:35.482146:    skip - SSID mismatch
> Feb 15 13:03:35.482163:    selected based on RSN IE
> Feb 15 13:03:35.482179: Trying to associate with aa:bb:cc:dd:ee:ff
> (SSID='CMU-WPA' freq=0 MHz)
> Feb 15 13:03:35.482192: Cancelling scan request
> Feb 15 13:03:35.482205: WPA: clearing own WPA/RSN IE
> Feb 15 13:03:35.482216: Automatic auth_alg selection: 0x1
> Feb 15 13:03:35.482236: RSN: using IEEE 802.11i/D9.0
> Feb 15 13:03:35.482249: WPA: Selected cipher suites: group 8  
> pairwise 16
> key_mgmt 1
> Feb 15 13:03:35.482275: WPA: set AP WPA IE - hexdump(len=26): dd 18 00
> 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 01 28 00
> Feb 15 13:03:35.482294: WPA: set AP RSN IE - hexdump(len=22): 30 14 01
> 00 00 0f ac 02 01 00 00 0f ac 04 01 00 00 0f ac 01 28 00
> Feb 15 13:03:35.482312: WPA: using GTK TKIP
> Feb 15 13:03:35.482325: WPA: using PTK CCMP
> Feb 15 13:03:35.482337: WPA: using KEY_MGMT 802.1X
> Feb 15 13:03:35.482350: WPA: Set own WPA IE default - hexdump(len=22):
> xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
>
> Same problem. :(
>
> On Wed, 2006-02-15 at 12:11 -0500, Brian Bender wrote:
>> 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
>>
>



