[wpa_supplicant] essid with non-ascii characters
j.witteveen at gmail.com
Mon Jul 30 08:10:51 EDT 2012
>> Message de Jouni Malinen: mar. 26/06/12, 12:55:45 +0300
>> It is not a problem with wpa_supplicant implementation, but in the way
>> the APs can be configured using different encoding.. Some operating
>> systems uses Latin 1, some use UTF-8, some something else.. Unless you
>> copy the SSID from scan results as-is (i.e., as binary data), you can
>> get a mismatch here..
> I see.
LuX and I did some experimenting and found the following:
printf "%q\n" \
"$(wpa_cli -i wlan0 -p /run/wpa_supplicant scan_results |\
$'01:23:45:67:89:ab\t2422\t-60\t[ESS]\tWifi Ch_teau d\'Olonne'
The network is supposedly named "Wifi Château d'Olonne", thus the
experiment shows that wpa_cli substitutes the 'â' with a '_'. If it
would just output whatever bytes are in the SSID, the result of the
printf would be usable in shell scripts to connect to the network.
>> In theory, wpa_supplicant could be extended to do matching with multiple
>> different encoding combinations (i.e., guess what encoding is used in
>> the SSID from the AP), but I'm not sure whether this would be worth the
>> effort taken into account that most configuration cases nowadays copy
>> the SSID automatically without manual entry and with advanced use cases
>> may prefer to avoid inexact matches.
The only problems I see with outputting the SSID as-is, is with '\n'
and '\t'. Both mess up the output of `wpa_cli scan_results`. One way
to solve this problem is to have ' ' match all three of them (spaces,
newlines and tabs), another is by introducing escaping.
More information about the HostAP