encodeext vs. encode codepaths

Dan Williams dcbw at redhat.com
Mon Jan 30 11:21:52 EST 2006


It seems like wpa_supplicant has issues with fallback to plain encode in
the wext driver.  For example, both atmel and airo drivers will not
connect when wpa_supplicant falls back to encode.

I've done patches for atmel and airo both that implement minimal
encodeext and auth wext handlers, and once that's done everything works
quite well.

So what's not being done in wpa_supplicant in the encode path that _is_
being done in the encodeext path that allows the cards to associate?
Any ideas?  Observations indicate that the ESSID isn't even getting set
on the airo card correctly when the fallback to encode happens.  It
never associates because it can't get the essid.

Like I said, I've patched airo to support encodeext and auth, which I'll
be posting to netdev in a bit.  But shouldn't wpa_supplicant support WEP
operation on these cards without encodeext?

I'm happy to send debug logs for both fallback->encode and with
encodeext if that would help.


More information about the HostAP mailing list