encodeext vs. encode codepaths

[Jouni Malinen]

On Mon, Jan 30, 2006 at 11:21:52AM -0500, Dan Williams wrote:

> 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.

Hmm.. That's odd.

> 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.

There should not be any difference in other ioctl calls. wpa_supplicant
tries SIOCSIWENCODE directly after SIOCSIWENCODEEXT fails with
EOPNOTSUPP. Have you checked whether the drivers/WE code in kernel is
returning -EOPNOTSUPP in this case is SIOCSIWENCODEEXT is not set?

> 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?

It should have.

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

Please do. I'm pretty sure I have tested this with couple of drivers,
though, not with atmel or airo. ndiswrapper was returning incorrect
error code (-ENODEV) and I have a workaround for that. However, I don't
know what is happening with airo/atmel.

-- 
Jouni Malinen                                            PGP id EFC895FA