Dmitry Shmidt dimitrysh at google.com
Thu Mar 17 18:36:32 EDT 2011

On Sun, Feb 27, 2011 at 3:46 AM, Jouni Malinen <j at w1.fi> wrote:
> On Thu, Feb 24, 2011 at 05:31:36PM -0800, Dmitry Shmidt wrote:
>> Subject: [PATCH] Add WPA_UNICODE_SSID support
> This change should not really be needed and can be problematic because
> SSID is not really unicode string (e.g., it can contain '\0').
>> diff --git a/src/utils/common.c b/src/utils/common.c
>> @@ -374,8 +374,10 @@ const char * wpa_ssid_txt(const u8 *ssid, size_t ssid_len)
>> +#ifndef WPA_UNICODE_SSID
>>               if ((u8) *pos < 32 || (u8) *pos >= 127)
>>                       *pos = '_';
>> +#endif
> I don't like the idea of making this a build time option. Furthermore,
> this is not going to work with some SSIDs and whatever is trying to
> parse the string does not have any indication of what encoding is used
> in the SSID.
> Can you please identify which strings you are using (i.e., which calls
> of wpa_ssid_txt() in wpa_supplicant affect the parsed string)? The
> current SSID in the STATUS command output should be extended by adding
> another field: ssid_hex=<hexdump> which would not have problems with
> '\0' (or '\n' for that matter) in the string. For the current scan
> results (BSS table), the new BSS command already provides the full set
> of IEs in hexdump format.

You are right, it is possible with new API to get scan results and
then to "clarify" SSID by BSS command.
The problem is that it is relatively slow and it is not 100% clear for
what network we need clarification.

>> +/* STR_* variants that do not force conversion to ASCII */
>> +#define _STR_UNICODE(f) #f, wpa_config_parse_str,
>> wpa_config_write_str_unicode, OFFSET(f)
>>  static const struct parse_data ssid_fields[] = {
>> +     { STR_RANGE_UNICODE(ssid, 0, MAX_SSID_LEN) },
>> +#else
>>       { STR_RANGE(ssid, 0, MAX_SSID_LEN) },
>> +#endif
> I don't understand this part at all.. Why would new parsing/writing
> routines be needed for string? The current ones have no problems parsing
> UTF8 (or other non-ASCII encoding for that matter) and the output is
> stored as a hexdump if there are any non-ASCII characters. When that
> is read in, the result is the exact same data that was originally read.
> As such, I do not think this change is needed and if nothing else, it
> breaks use of '\0' in the SSID.

You are right, let me check what was the problem we tried to resolve here.

> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap

More information about the HostAP mailing list