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<[email protected]>
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 _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
