[PATCH] Re: encodeext vs. encode codepaths
dcbw at redhat.com
Wed Feb 1 11:11:18 EST 2006
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.
More information about the HostAP