[PATCH] Re: encodeext vs. encode codepaths

[Dan Williams]

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

If that sounds good, I can make a patch and post it.

Dan