Re: [RFC] Wireless extensions rethink

[Gerald Britton <gbritton@doomcom.org>]

On Wed, Jun 16, 2004 at 10:53:38AM -0700, Scott Feldman wrote:
> On Wed, 2004-06-16 at 08:28, Gerald Britton wrote:
> > A few comments below.
> > [snip]
> > > +	char	essid[32];	/* ESSID; any = NULL string */
> > 
> > This isn't sufficient as you can have \0 bytes in the ESSID so treating it
> > as a null-terminated string is probably not ideal.  Also the spec specifies
> > 32 characters as a max, but the 802.11 management IE's could support upto
> > 255 character essid's, this probably needs a little extra thought.
> 
> Ok, how about
> 
> 	u8	essid[32];	/* ESSID; any = all zeros */
> 
> On the size, include/linux/wireless.h has it defined as 32:
> 
> /* Maximum size of the ESSID and NICKN strings */
> #define IW_ESSID_MAX_SIZE       32

IMHO, this is a flaw in the current wireless extensions.  Your idea doesn't
provide any way to determine the actual size of the data.  ssids of \0\0 and
\0\0\0 differ.  I like Vladimir Kondratiev's suggestion of defining things
in terms of info elements (IE's).  This is how they get encoded in the frames
sent over the air.

> > > +	char	sec_key[32];	/* Security mode encryption key */
> > 
> > Similar here, is 32 characters worth of "key" enough here.
> 
> include/linux/wireless.h has it defined as 32:
> 
> /* Maximum size of the encoding token in bytes */
> #define IW_ENCODING_TOKEN_MAX   32      /* 256 bits (for now) */

IMO, simply following the wireless extentions is probably the wrong way to
approach this, there is the opportunity to redesign things to better fit
the actual needs of a generic ieee 802.11 stack in the kernel, and of the
existing and likely future drivers. The current wireless extentions in many
areas attempt to be over generic with interfaces which I've never seen a
device actually implement to others whre the API ends up limiting you (like
the ssid and key setting here).

> > Also a quick thought to settings many drivers have in their iwpriv
> > commands such as operating modes .11b/.11a/.11g/auto.  A survey of a bunch
> > of drivers is probably worth doing to collect where the previous wireless
> > extentions didn't really fit their needs.
> 
> So far we've only looked at the standard settings, but you're right, we
> should move commonly used private settings over to the standard set. 
> There are some drivers (i.e. prism54) that use module params that are
> duplicates of the standard settings.  These need cleaning up as well.
> 
> -scott

Yeah.  a handful of examples i can think of off the top of my head:
antenna selection (diversity), beacon intervals, roaming settings,
promiscuous mode within a bssid vs. fully promiscous receive (this
one is probably highly dependant on generic 802.11 stack support).

				-- Gerald