[Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)

[Simon Schampijer]

On 04/02/2012 06:40 PM, Sascha Silbe wrote:
> IEEE 802.11 [2] defines the SSID as a sequence of octets (i.e. bytes), but
> Sugar treated it as UTF-8 character data. While in most cases the SSID is
> actually some human-readable string, there's neither a guarantee for that nor
> does any (de-facto or de-jure) standard specify the encoding to use. As a
> result, we'll encounter SSIDs in a large variety of encodings and will also
> need to cope with arbitrary byte strings. Any assumption of a single (or in
> fact any) character encoding is incorrect.
>
> The D-Bus API of NetworkManager 0.9 [3] passes SSIDs as uninterpreted byte
> strings (D-Bus signature "ay"). Before SSIDs can be displayed on screen, some
> kind of interpretation must happen.
>
> NetworkManager has a rather elaborate heuristic that takes the user locale into
> account. In the future (i.e. when the NetworkManager client code in Sugar has
> been ported to gobject-introspection) we may use nm_utils_ssid_to_utf8() [4],
> but for now we're doing the following to allow the user to use non-UTF-8 APs at
> all:
>
> 1. If the SSID is a valid character string consisting only of
>     printable characters in one of the following encodings (tried in
>     the given order), decode it accordingly:
>     UTF-8, ISO-8859-1, Windows-1251.
>
> 2. Return a hex dump of the SSID.
>
> The first rule should cover the majority of current Sugar users and hopefully
> all AP vendors will switch to UTF-8 eventually. In the meantime, the second
> rule allows users to distinguish between several APs with SSIDs in unknown
> encodings (or even using arbitrary byte sequences that don't _have_ a character
> representation).
>
> Tested:
> - filtering on ASCII and non-ASCII parts of the name of and connecting to:
>    - an unsecured AP with a UTF-8 SSID ("äöü߀sugartest", HostAP)
>    - an unsecured AP with an ISO-8859-1 SSID ("äöüßsugartest", HostAP)
>    - an unsecured AP with a non-character SSID (0d:06:f0:0d, HostAP)
>    - a WEP-secured AP with a UTF-8 name ("äöü߀sugartest2", HostAP)
>    - a WEP-secured AP with an ISO-8859-1 name ("äöüßsugartest2", HostAP)
>    - a WEP-secured AP with a non-character SSID (0d:06:f0:0d, HostAP)
>    - a WPA-secured AP with an ASCII name (COTS AP)
>
> In each case the name was displayed correctly in
> a) the palette of the AP icon in the Neighbourhood,
> b) the palette of the wireless network Frame device and
> c) the title of the WLAN credentials (WEP/WPA passphrase) dialog (for
>     the WEP/WPA cases).
>
> [1] https://bugs.sugarlabs.org/ticket/2023
> [2] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
> [3] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
> [4] http://projects.gnome.org/NetworkManager/developers/libnm-util/09/libnm-util-nm-utils.html#nm-utils-ssid-to-utf8
>
> Signed-off-by: Sascha Silbe<silbe at activitycentral.com>

Thanks for the patch, looks good. I tested here with my AP that does 
announce in non utf-8 char and it works fine.

I still don't see the hex-dump as needed but ok, if you have tested it, 
I am happy with it.

I opened #3451 to track the porting to use "nm_utils_ssid_to_utf8" from 
libnm.

Regards,
    Simon