[wpa_supplicant] essid with non-ascii characters

[LuX]

Hello!

Thanks to both of you for your replies. 

> On Mon Jun 25 17:47:42 EDT 2012, Nicolas Cavallari wrote:
> [mandatory joke about latin9 users still living in a castle omitted, as
> this is maybe the case]

Excellent!   :-))))

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

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

According to manuals (and Arch Linux's wiki) the typical way of using
wpa_supplicant consists in creating a /etc/wpa_supplicant.conf file and
applying wpa_supplicant to it. Since such encoding problems are quite
misleading, I think that it would be worth to:

1) Advertise them in the man page of wpa_supplicant. 

2) If it doesn't exist, create an intermediate tool between iwlist and
wpa_supplicant in order to build from the output of a scan a
pre-version of wpa_supplicant.conf (to be continued by the user for
passphrases and so on, but with an 'essid' field already completed,
with the correct encoding).

Of course this is no longer a bug, but I am considering to ask it as a
feature. What do you think about it? 

Regards, 
LuX