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

Dan Williams dcbw at redhat.com
Thu Jan 12 11:59:01 EST 2006


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




More information about the HostAP mailing list