Jouni Malinen j
Sun Feb 27 03:46:38 PST 2011

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

> +/* 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[] = {
> +#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.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list