[PATCH] [updated] encodeext vs. encode codepaths

[Dan Williams]

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

Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wpa_supplicant-auth-fallback-v2.patch
Type: text/x-patch
Size: 8408 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20060202/81a5881d/attachment.bin