| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent versions of the kernel export the Open Firmware device tree to
user space as /proc/device-tree, rather than /ofw (the latter was
specific to OLPC kernels). We checked for existence of /ofw to determine
whether we're running on an OLPC XO and assumed it's running
olpc-powerd, since that is what we actually try to control. By checking
for a directory created by olpc-powerd, we make sure that it's actually
available (to us) and works on any kernel version.
Check if powerd is available to determine if the power section
is displayed or not.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Sascha Silbe <silbe@activitycentral.com>
|
