| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Recent versions of NetworkManager have gotten stricter when checking
UUIDs. A UUID must be 32 hex characters plus 4 dashes.
Sugar's unique_id() doesn't satisify this. Switch to using
uuid.uuid4 from the uuid python module to generate UUIDs.
[1] http://docs.python.org/library/uuid.html
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run sugar-convert.sh [1] for automatic conversion from sugar.* imports to
sugar3.* imports. This is only on a best-effort basis; the code will
be in a broken state after this patch and need to be fixed manually.
The purpose of committing the intermediate, non-working output is to make it
reproducible. It's impractical to manually review the changes.
[1] http://dev.laptop.org/~manuq/sugar-convert.sh
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run pygi-convert.sh for automatic conversion from GTK+ 2 to GTK+ 3 and
pygobject+gobject-introspection. This is only on a best-effort basis;
the code will be in a broken state after this patch and need to be
fixed manually.
The purpose of committing the intermediate, non-working output is to make it
reproducible. It's impractical to manually review the changes.
The exact version used was 2d8f48f4ff56bb75985136452b50b75895258608 from the
main pygobject repository [1].
[1] git://git.gnome.org/pygobject
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@activitycentral.com>
Reviewed-by: Daniel Drake <dsd@laptop.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adapt sugar to NetworkManager-0.9 API changes.
The major change here is the removal of the user-level connections
mechanism; instead of storing connection information in Sugar,
NetworkManager now Manages our Networks for us.
However, some level of interfacing/monitoring NM is now needed,
implemented with the Connections and Connection classes in
jarabe.model.network.
If found, connections in sugar's connections.cfg are automatically
migrated, and then connections.cfg is deleted. Similarly, if modem
connection details are found in gconf, they are migrated into NM
and then the gconf keys are unset.
The existing network code is far from perfect and actually quite messy.
In this port I've tried not to make fundamental changes to improve this,
in order to keep task complexity down and aid review.
In the medium term I do plan to improve this code, by moving it to
use gobject-introspection on libnm, and rewriting/restructuring at the
same time. By letting libnm do most of the work for us, this layer can
be greatly simplified. However, libnm and gobject-introspection
improvements are needed first, which I will continue to work on.
Modem PUK configuration has been removed as NetworkManager no longer
has configuration for this. It hasn't been used (and was marked
deprecated) throughout the NM-0.8 release series.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting the 'autoconnect' property for the connection
will let NM do the reconnection when the device is up. If
the Sugar Ad-hoc network is around it will automatically
connect to it. The connection is not stored after logging
out of Sugar.
The autoconnect functionality inside Sugar is still needed
for the cases when we log into Sugar, after a timeout we
will connect to an exisiting Ad-hoc network or will default
to the Sugar Ad-hoc network on channel 1. I increased the
timeout to 60 seconds because during testing I found to
get more reliable results like that.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-By: Sascha Silbe <silbe@activitycentral.com>
|
| |
|
|
|
| |
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-By: Sascha Silbe <silbe@activitycentral.com>
|
| |
|
|
|
|
|
| |
[split out from larger "fix network disconnect and discard history" patch;
fixed up all remaining occurences as well]
Signed-Off-By: Sascha Silbe <silbe@activitycentral.com>
Reviewed-By: Sascha Silbe <silbe@activitycentral.com>
|
| |
|
|
|
|
|
|
|
| |
Tomeu prefers ' for strings, so let's use it wherever we don't have a good
reason to use ".
Reviewed-by: James Cameron <quozl@laptop.org>
Reviewed-by: Simon Schampijer <simon@laptop.org>
CC: Aleksey Lim <alsroot@member.fsf.org>
|
| |
|
|
|
|
| |
Reviewed-by: James Cameron <quozl@laptop.org>
Reviewed-by: Simon Schampijer <simon@laptop.org>
CC: Aleksey Lim <alsroot@member.fsf.org>
|
| |
|
|
|
|
| |
Reviewed-by: James Cameron <quozl@laptop.org>
Reviewed-by: Simon Schampijer <simon@laptop.org>
CC: Aleksey Lim <alsroot@member.fsf.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This only touches the globals that were flagged by pep8 due to white space
issues or contain "instance" in their name (singleton pattern).
I've also left the sunflower layout variables alone. AFAICT this layout is
currently unused and should be removed instead (or factored out like the snow
flake layout and reenabled).
Reviewed-by: James Cameron <quozl@laptop.org>
Reviewed-by: Simon Schampijer <simon@laptop.org>
CC: Aleksey Lim <alsroot@member.fsf.org>
|
| |
|
|
| |
isn't in the DISCONNECTED state.
|
|
|
This patch adds three default Ad-hoc networks, for channel 1, 6 and 11. They
are represented with designated icons in the neighborhood view. This will
mimic the mesh behavior on devices where mesh hardware is not available
and make the "under a tree"-scenario possible in those cases. If Sugar sees
no "known" network when it starts, it does autoconnect to an Ad-hoc network.
http://wiki.sugarlabs.org/go/Features/Sugar_Adhoc_Networks
|
