Update to Re: [Madwifi-devel] WPA Branch & Xsupplicant

[Terry S. <gal...@ma...>]

Woops let me rephrase that last thought:

I get a new unicast key from my HP 420 every minute, and traffic 
continues to flow.

On my D-Link DWL 900AP+, after I get my broadcast first, then my 
unicast key, I can pass traffic until I get the next broadcast key at 
which point traffic ceases to flow.

So I really think the problem has to do with a broadcast EAPoL key 
being set *after* the EAPoL unicast key is set, but it is *NOT* because 
the broadcast EAPoL key becomes the *transmit* key... iwlist key ath0 
shows that the transmit key is still on the correct slot, and the key 
is correct too, but traffic won't flow.

Thanks!

- Terry

On Jun 23, 2004, at 9:57 PM, Terry Simons wrote:

> I made a little bit more progress on this.
>
> I am completely wrong about the keying... the transmit key is still 
> the same after a broadcast key set (as evidenced by iwlist key ath0).
>
> Something else is going on in the driver that is causing traffic to 
> stop flowing.
>
> I have verified this by authenticating against my HP 420, which ONLY 
> sends unicast keys (don't ask...)
>
> I get a new key every minute, and traffic continues to flow after 
> successive key sets, so I really think the problem has to do with 
> setting a broadcast key *after* a unicast key is received, but it is 
> *NOT* because the broadcast (or should I say multicast?) key becomes 
> the unicast key...
>
> - Terry
>
> On Jun 23, 2004, at 9:12 PM, Terry Simons wrote:
>
>> Ok, so it looks like I spoke too soon about the 802.1X support in the 
>> WPA branch... it still has one of the bugs experienced with the HEAD 
>> branch.
>>
>> I'll do some digging and see if I can figure it out...
>>
>> The problem is:
>>
>> After 802.1X authentication, when a broadcast key is sent after the 
>> initial unicast (tx) key, I can no longer pass traffic.  Everything 
>> is fine until my AP sends me a new broadcast key.  (This was the same 
>> behavior that the patch fixed).
>>
>> Sam, do you have any idea what the problem might be?  I see that the 
>> code is only setting the tx key when we get a key set of length 0, 
>> and I know that xsupplicant works there... but the MADWifi driver 
>> still seems to be doing *something* when we get a broadcast key that 
>> is goofing things up.
>>
>> My test AP, which is really broken, sends a new broadcast key every 2 
>> seconds, which is very useful for triggering this problem. ;-)
>>
>> I can 802.1X authenticate (and pass traffic) just fine with other 
>> drivers in Linux, WIndows, and Mac OS X on this same AP.
>>
>> In my particular case, the keys arrive in this order: broadcast, 
>> unicast... which makes me wonder if the keys were flipped (unicast 
>> first, then broadcast) would the problem appear immediately?
>>
>> It seems to me almost as if the driver is still setting the tx key to 
>> be the broadcast key (or something weird like that), even though that 
>> seems contrary to the way I'm reading the code.
>>
>> Any ideas?
>>
>> - Terry
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
>> self defense, top technical experts, no vendor pitches, unmatched 
>> networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Madwifi-devel mailing list
>> Mad...@li...
>> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
>