[PATCH] [updated] encodeext vs. encode codepaths
Wed Feb 1 21:07:58 PST 2006
On Wed, 2006-02-01 at 11:11 -0500, Dan Williams wrote:
> On Wed, 2006-02-01 at 00:42 -0500, Dan Williams wrote:
> > 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.
> This patch doesn't appear to work with WPA_ALG_NONE, because there is no
> way yet to pass the WPA_ALG_* into the set_auth_alg() calls in the
> driver. We need to do this so we can set the IW_ENCODE_DISABLED bit
> when we set the other bits in wpa_driver_wext_set_auth_alg().
> What's the best way to pass this information in? We essentially just
> need a boolean value to say "will we have an encrypted connection or
> not". I was thinking to augment the driver's set_auth_alg() algorithm
> with an int, either 0 or 1, that indicated whether or not encryption
> would be set.
> Could the wpa_drv_set_auth_alg(wpa_s, algs); call possibly be moved down
> a few lines to be just below the KEY_MGMT_NONE ||
> KEY_MGMT_IEEE8021X_NO_WPA block where the wep keys are set? Then we
> could pass 'use_crypt' into wpa_drv_set_auth_alg(), which would pass it
> along to the driver-specific function, which could do whatever it wanted
> to with that information (including falling back to ENCODE and setting
> If that sounds good, I can make a patch and post it.
The proposed patch is attached. I also corrected invalid usage of the
IW_ENCODE_MODE mask in driver_wext.c from the original patch. I had
been using it as a flag, not a mask.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8408 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20060202/81a5881d/attachment.bin
More information about the Hostap