[PATCH] wpa_supplicant: Work around odd driver-reported ssid lengths

[Pedro Ramalhais]

On Thu, 2006-01-12 at 11:59 -0500, Dan Williams wrote:
> On Thu, 2006-01-12 at 16:54 +0000, Pedro Ramalhais wrote:
> > On Thu, 2006-01-12 at 11:30 -0500, Dan Williams wrote:
> > > Hi,
> > > 
> > > At least the atmel and airo drivers do odd, technically incorrect,
> > > things in their SIOCGIWESSID:
> > > 
> > >         memcpy(extra, status_rid.SSID, status_rid.SSIDlen);
> > >         extra[status_rid.SSIDlen] = '\0';
> > >         /* If none, we may want to get the one that was set */
> > > 
> > >         /* Push it out ! */
> > >         dwrq->length = status_rid.SSIDlen + 1;
> > > 
> > > Atmel does roughly the same thing.  They both append a '\0' to the end,
> > > and push that to userspace.  I'm unsure whether or not NULL is a legal
> > > character in an SSID, but these drivers do it.
> > > 
> > > wpa_supplicant does not handle it; in the wpa_supplicant_get_ssid()
> > > function, it compares the internal SSID from the config file to the
> > > value returned by the driver.  If the lengths of the two do not match,
> > > no wpa_ssid structure is returned.  In this odd case, then lengths do
> > > not match, but the AP is clearly the correct AP to use.
> > > 
> > > Patch attached.  It checks if the last byte of the SSID reported by the
> > > driver is NULL, and if so, decrements the driver-reported length.  I
> > > think this is an acceptable solution.
> > > 
> > > Thanks,
> > > Dan
> > 
> > AFAIK an ESSID is a length of bytes and 0 ('\0' or NULL) is a valid
> > byte. The problem is that some applications use (or used) the ESSID
> > directly to print it, and so, they rely on having a 0 at the end of the
> > string. I'm not sure how wireless tools handles it, and i don't know if
> > it does it in the correct way.
> 
> I'd guess that the # of people using 0 as the last byte of their ESSID
> is much smaller than the number of people using either atmel or Airo
> cards though...  So does wpa_supplicant work around the broken drivers
> (which should get fixed), or does wpa_supplicant just not work with
> these drivers/cards?
> 
> I'd personally vote for (1) where it works around the drivers, and the
> drivers get fixed upstream at the same time.
> 
> Dan
> 

I probably didn't make myself clear in my previous message.
I only tried to explain why some drivers used to do that.
The correct thing should be made and not touch the ESSID.
The user interface should use smoe kind of way to let the user input any
value into the ESSID. ex: iwconfig eth1 essid \000nulls\000are\000fun
and should also present that information to the user when requested.
Right now i don't think apps show you nulls and such non-printable
bytes.
-- 
Pedro Ramalhais <ramalhais at serrado.net>