Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate
summaryrefslogtreecommitdiffstats
path: root/extensions
Commit message (Collapse)AuthorAgeFilesLines
* Don't treat SSID as UTF-8 character sequence (fixes SL#2023)Sascha Silbe2012-04-231-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a backport of 7f8ba95a66780828531eba0494e004757bf45c71. 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) 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 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@activitycentral.com>
*