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

[Paul Lambert]

On Jan 12, 2006, at 9:29 AM, Pedro Ramalhais wrote:

> 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.

Any character is valid in an SSID.  It's a mistake in the  
specification (IMHO)
that now is misused by vendors.  Some clients actively probe using
some unusual 32 char hex values ...

>>
>> 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.

I've never seen a user interface that allows non-ascii characters.
Human configured SSIDs should not require unprintable characters
(like nulls).

Paul



> -- 
> Pedro Ramalhais <ramalhais at serrado.net>
>
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap