[PATCH] Re: encodeext vs. encode codepaths
dcbw at redhat.com
Wed Feb 1 00:42:30 EST 2006
On Mon, 2006-01-30 at 19:34 -0800, Jouni Malinen wrote:
> 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?
On the non-ENCODEEXT codepath, wpa_supplicant never sets the WEP
authentication mode. So even if you set a key on the card, it never
knows whether to do Open System or Shared Key or whatever. The attached
patch works for airo at least and likely also for atmel.
In any case, I've submitted patches (which have been accepted as of
post-2.6.15) for both airo and atmel that implement WEP ENCODEEXT and
AUTH, but this should cover those drivers before 2.6.15.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1696 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20060201/79325998/attachment.bin
More information about the HostAP