encodeext vs. encode codepaths
jkmaline at cc.hut.fi
Mon Jan 30 22:34:17 EST 2006
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
More information about the HostAP