Re: WPA with ath

Tai-hwa Liang wrote:
> On Sat, 22 Jan 2005, Sam Leffler wrote:
> 
>> Bryan Bunch wrote:
>>
>>> I'm trying to connect to a Linksys WRT54G. I have tested the card on
>>> the computer when booting up in XP and it connects fine via WPA. I
>>> also tested the card in CURRENT with WPA disabled and the card
>>> connected fine.
>>
>>
>> There's nothing useful in the log you included.  You can get the 
>> reason code sent by the ap by enabling association debugging in the 
>> 802.11 layer.  I usually do this with the 80211debug program found in 
>> /usr/src/tools/tools/ath.  Something like
>>
>> 80211debug +assoc+auth
>>
>> should suffice.  Messages go to the console.
>>
>> I've seen postings in various forums that this AP has issues with 
>> certain firmware revs; you might check if your firmware is up to date.
>>
>> Past the above a packet trace is needed.
> 
> 
> Hi Bunch,
> 
>   According to WPA for 802.11i, section 2.2.2:
> 
>     The only unencrypted data packets allowed are unicast 802.1X
>     data packets and unencrypted 802.1X data packets are only
>     allowed when there is no Pairwise key between the station
>     and AP otherwise unencrypted data packets must be discarded.
> 
>   I guess that's why your station being deauthenticated right after
> seeing "Group rekeying completed with..." since WPA requires station
> sending group EAPOL key in encrypted form once the pairwise key is
> available and installed.
> 
>   In my testing environment, -CURRENT if_ath + wpa_supplicant 0.3.0
> always being kicked out by Buffalo AirStation G54 AP(firmware 2.20)
> after station completed the group key handshake; however, the same
> station/software configuration works flawlessly(read: only one 4-way
> handshake + 2 way group key exchange) with another Orinoco AP(which
> allows station to reply the last EAPOL successful message in plaintext).
> 
>   The attached patch works on my box. Would you please give it a try?
> 

Yes, that makes sense.  wpa_supplicant sets up the unicast key in the 
shared key area and not in the per-node unicast key slot so we're 
checking the wrong place for a key.  Thank you.

	Sam