[PATCH] [updated] encodeext vs. encode codepaths

[Dan Williams]

On Sun, 2006-02-05 at 17:51 -0800, Jouni Malinen wrote:
> On Thu, Feb 02, 2006 at 11:10:13AM -0500, Dan Williams wrote:
> > On Wed, 2006-02-01 at 21:24 -0800, Jouni Malinen wrote:
> > > On Thu, Feb 02, 2006 at 12:07:58AM -0500, Dan Williams wrote:
> > > 
> > > > 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.
> > > 
> > > Thanks! I haven't yet had a chance to look at the details, but I'll try
> > > to do that over the weekend. Just a quick note on one of the changes:
> > > it is highly preferred that the driver wrapper API defined in driver.h
> > > remains backwards compatible at source code level (i.e., does not
> > > require changing driver_*.c files).
> > 
> > Yeah, I was looking for another way that wasn't a hack, but couldn't
> > fine one.  Likely I'm not as familiar with the source.  I don't like
> > breaking API, but I'm not sure of another way to do set_auth_alg()
> > fallback without passing use_crypt into the set_auth_alg() handler.
> 
> > For the above reasons, it would be messy to punt the auth_alg fallback
> > stuff into associate() handler.  You've got a problem here then; the
> > SIOCSIWAUTH codepath auth_alg goes through set_auth_alg(), but the
> > ENCODE-fallback codepath is in associate().
> 
> OK, I see your point. In the past, I've added a new handler function if
> an incompatible change is needed. The old handler will then be
> deprecated, but will continue to be supported for quite a long while.
> This adds some extra code, but not that much, and allows smoother
> transition to new driver handler API.
> 
> > 1) wpa_supplicant was not setting authentication algorithm at _all_ for
> > cards that don't support SIOCSIWAUTH
> 
> One reason for this is that I've never seen such a mechanism in Linux
> wireless extensions before SIOCSIWAUTH.. Your patch seems to be using
> IW_ENCODE_OPEN for Open System authentication and IW_ENCODE_RESTRICTED
> for Shared Key authentication. However, for me, these means something
> completely different, i.e., whether unencrypted frames are accepted or
> not when WEP is used. I think there has been confusion on what these
> parameters really mean and I'm not sure what the original purpose was.
> Do you happen to have good understanding on which drivers use
> IW_ENCODE_OPEN/RESTRICTED flags to select between Open System and Shared
> Key authentication algorithms?
> 
> > 2) To fall back to ENCODE, you need to know whether encryption will be
> > enabled or disabled so you can add the IW_ENCODE_DISABLED flag before
> > calling ENCODE.  There was no way to pass this into set_auth_alg(),
> > because set_auth_alg() is just an 'int' for the algorithm.
> 
> set_auth_alg() should actually go away and be replaced with
> associated(). I don't think I've marked it deprecated yet, but it is
> just making things difficult with some drivers and I've already added
> auth_alg parameter to struct wpa_driver_associate_params so that
> associate() hander has all the needed information. Static WEP keys may
> need to be added there to allow easier configuration.
> 
> > Hopefully you can come up with something clever here, but at the point
> > we set the auth on the card using ENCODE, we need to know whether
> > encryption will be enabled or not.
> 
> This is the part that is somewhat strange for me since I've never used
> ENCODE ioctl to set auth_alg. Getting all the needed information into
> associate() and remove set_auth_alg() handler would be preferred to make
> this cleaner, regardless of whether ENCODE is used or not here.
> 
> > -- Expand wpa_driver_associate_params to include a
> > "delayed_auth_fallback" flag, which is set in set_auth_alg() and
> > actually processed in authenticate().
> > 
> > If that sounds good, I'll do a patch for that instead.  Sounds like a
> > kludge, but would preserve backward source compatibility.
> 
> Thanks. This is indeed preferred when comparing to the previous patch.
> Anyway, I think I'll take a look at whether we could make associate()
> handler this properly and just deprecate separate set_auth_alg()
> handler.

Any status on this?  I'm carrying a variation of my most recent patch in
the Fedora Core distribution's wpa_supplicant since it needs to reliably
work with non-ENCODEEXT/non-AUTH drivers...  Seems to work OK at the
moment.

Dan