netdev
[Top] [All Lists]

Re: [RFC] Wireless extensions rethink

To: Gerald Britton <gbritton@xxxxxxxxxxx>
Subject: Re: [RFC] Wireless extensions rethink
From: Scott Feldman <sfeldma@xxxxxxxxx>
Date: Wed, 16 Jun 2004 10:53:38 -0700
Cc: Gertjan van Wingerde <gwingerde@xxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20040616152808.GA6270@fog.sekrit.org>
References: <C6F5CF431189FA4CBAEC9E7DD5441E0103AF626C@orsmsx402.amr.corp.intel.com> <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <20040616152808.GA6270@fog.sekrit.org>
Reply-to: sfeldma@xxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
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
                                                                            > 
[snip]
> > +   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) */
                                                                        
> 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


<Prev in Thread] Current Thread [Next in Thread>