[PATCH] [updated] encodeext vs. encode codepaths

[Jouni Malinen]

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.

-- 
Jouni Malinen                                            PGP id EFC895FA