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

Wed Feb 15 10:10:26 PST 2006

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
> 