[PATCH] libnm-util: accept old-style UUIDs as valid

[Daniel Drake]

Old versions such as 0.9.4 generated 40-character UUIDs with no
hashes, but libnm-util regards them as invalid. That means that
existing connections stop working when upgrading from 0.9.4.

Continue accepting such UUIDs as valid, and add a test so that
we don't forget in future.
---
 libnm-util/nm-utils.c   |  9 -
 libnm-util/tests/test-general.c | 24 
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/libnm-util/nm-utils.c b/libnm-util/nm-utils.c
index e869e0a..c0b18f6 100644
--- a/libnm-util/nm-utils.c
+++ b/libnm-util/nm-utils.c
@@ -2264,5 +2264,12 @@ nm_utils_is_uuid (const char *str)
p++;
}
 
-   return (num_dashes == 4) && (p - str == 36);
+   if ((num_dashes == 4) && (p - str == 36))
+   return TRUE;
+
+   /* Backwards compat for older configurations */
+   if ((num_dashes == 0) && (p - str == 40))
+   return TRUE;
+
+   return FALSE;
 }
diff --git a/libnm-util/tests/test-general.c b/libnm-util/tests/test-general.c
index ff89128..3e6cee7 100644
--- a/libnm-util/tests/test-general.c
+++ b/libnm-util/tests/test-general.c
@@ -2075,6 +2075,29 @@ test_setting_802_1x_changed_signal (void)
g_object_unref (connection);
 }
 
+static void
+test_setting_old_uuid (void)
+{
+   GError *error = NULL;
+   NMSetting *setting;
+   gboolean success;
+
+   /* NetworkManager-0.9.4.0 generated 40-character UUIDs with no dashes,
+* like this one. Test that we maintain compatibility. */
+   const char *uuid = "f43bec2cdd60e5da381ebb1eb1fa39f3cc52660c";
+
+   setting = nm_setting_connection_new ();
+   g_object_set (G_OBJECT (setting),
+ NM_SETTING_CONNECTION_ID, "uuidtest",
+ NM_SETTING_CONNECTION_UUID, uuid,
+ NM_SETTING_CONNECTION_TYPE, NM_SETTING_WIRED_SETTING_NAME,
+ NULL);
+
+   success = nm_setting_verify (NM_SETTING (setting), NULL, &error);
+   g_assert_no_error (error);
+   g_assert (success == TRUE);
+}
+
 int main (int argc, char **argv)
 {
GError *error = NULL;
@@ -2106,6 +2129,7 @@ int main (int argc, char **argv)
test_setting_compare_vpn_secrets (NM_SETTING_SECRET_FLAG_NOT_SAVED, 
NM_SETTING_COMPARE_FLAG_IGNORE_NOT_SAVED_SECRETS, TRUE);
test_setting_compare_vpn_secrets (NM_SETTING_SECRET_FLAG_NONE, 
NM_SETTING_COMPARE_FLAG_IGNORE_SECRETS, TRUE);
test_setting_compare_vpn_secrets (NM_SETTING_SECRET_FLAG_NONE, 
NM_SETTING_COMPARE_FLAG_EXACT, FALSE);
+   test_setting_old_uuid ();
 
test_connection_to_hash_setting_name ();
test_setting_new_from_hash ();
-- 
1.8.3.1

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Change in UUID format breaks connections on upgrades

[Daniel Drake]

On Thu, Sep 5, 2013 at 4:05 PM, Dan Williams  wrote:
> Looks like 74b6b9c768338ce3cd58d781fd837e6abbf3e209 is to blame;
> previously the function didn't count the number of dashes, but now it
> does.  I guess I'd be fine with changing the check at the end of
> nm_utils_is_uuid() to:
>
> if ((num_dashes == 4) && (p - str == 36))
> return TRUE;
> /* Backwards compat for older configurations */
> if ((num_dashes == 0) && (p - str == 32))
> return TRUE;
> return FALSE;
>
> It also wouldn't hurt to have a testcase in
> libnm-util/tests/test-general.c that creates a new NMSettingConnection
> and sets the UUID to the old format and ensures that nm_setting_verify()
> still works.

Thanks, that sounds good. I wrote the test and made that change.

I will test it on Saturday then send a patch.

Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Change in UUID format breaks connections on upgrades

[Daniel Drake]

Hi,

I am working with a large OLPC deployment in Nicaragua performing a
software upgrade. The previous software release included
NetworkManager-0.9.4.0 and the new one includes
NetworkManager-0.9.8.1.

After performing the upgrade, NetworkManager does not connect to any
of the wireless networks that it used to. The files are still there in
/etc/NetworkManager/system-connections, but it is like they are
ignored.

Looking in the logs:

keyfile: parsing FZT_Cisco_AP
Connection failed to verify: (unknown)
keyfile: error: invalid or missing connection property
'NMSettingConnection/uuid'

It looks like at some point, NM has changed its UUID format, and has
stopped accepting the old one, which is like this:
uuid=f43bec2cdd60e5da381ebb1eb1fa39f3cc52660c

Would it be possible to relax this check so that compatibility is retained?

I would be happy to send in a patch that tweaks nm_utils_is_uuid() accordingly.

Thanks
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] wifi: don't remove AP upon link lost event

[Daniel Drake]

On Fri, May 10, 2013 at 12:14 PM, Dan Williams  wrote:
> The supplicant has a BSS timeout too, and APs don't get removed from the
> supplicant's list until the next scan after the timeout happens.  So it
> could be long after you're out of range, and that means NM would keep
> trying to reconnect to the AP that's not there because it doesn't know
> it's gone.
>
> There's no good way to know that an AP isn't in range anymore besides
> probe-scanning for it after you lose the connection to it, which would
> be a good thing to do.  But would also require some supplicant
> enhancements.

OK, the approach in your patch makes sense. I've been running it all
day, the AP has kicked me off several times and each time NM recovers
nicely.

Thanks
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] wifi: don't remove AP upon link lost event

[Daniel Drake]

On Thu, May 9, 2013 at 5:19 PM, Dan Williams  wrote:
> So the code in link_timeout_cb() only gets run when the wifi device is
> already connected and then somehow gets disconnected.  Were you hitting
> this issue while connected to the AP, getting disconnected, and then the
> AP rejected the reconnect?

You are frighteningly familiar with this code. That is exactly what happens.

> This patch will break the AP-out-of-range or AP-turned-off cases; so
> instead of your patch, does this one fix your issue?  We're already
> tracking whether or not the supplicant can talk to the AP, and the AP
> shouldn't be rejecting you during the AUTH phase, just the ASSOC phase.
> So with this patch, if when the supplicant reconnects it's able to get
> to the ASSOC phase, the AP shouldn't get removed from the list on link
> timeout.

I had assumed that the AP-out-of-range and similar cases would be
handled with a signal from the supplicant saying "BSS removed".
Anyway, your patch works.

Thanks
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] wifi: don't remove AP upon link lost event

[Daniel Drake]

When the link is lost, it doesn't mean that the AP has gone away.
It might just be overloaded or have rejected an association attempt
for an temporary reason.

The behaviour described in the comment removed here was not true
in such circumstances. As the supplicant never "loses sight" of the AP,
further scans will not generate "new BSS" signals for this AP, which is
what would be needed for the the AP to be found again in the next scan.

Instead, just leave the AP in the list and trust wpa_supplicant to handle
this case.

Fixes a bug where my unreliable AP sometimes rejects association
momentarily, but upon such event, NM was removing the network from the
list and never readding it, which left me unable to attempt to reconnect.
---
 src/devices/nm-device-wifi.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/src/devices/nm-device-wifi.c b/src/devices/nm-device-wifi.c
index 2b8ddd1..2340509 100644
--- a/src/devices/nm-device-wifi.c
+++ b/src/devices/nm-device-wifi.c
@@ -2180,19 +2180,7 @@ link_timeout_cb (gpointer user_data)
if (nm_device_get_state (dev) != NM_DEVICE_STATE_ACTIVATED)
return FALSE;
 
-   /* Remove whatever access point we used to be connected to from the list
-* since it failed and might no longer be visible.  If it's actually 
still
-* there, we'll find it in the next scan.
-*/
-   if (priv->current_ap) {
-   ap = priv->current_ap;
-   priv->current_ap = NULL;
-   } else
-   ap = nm_device_wifi_get_activation_ap (self);
-
-   if (ap)
-   remove_access_point (self, ap, TRUE);
-
+   priv->current_ap = NULL;
nm_device_state_changed (dev,
 NM_DEVICE_STATE_FAILED,
 priv->ssid_found ? 
NM_DEVICE_STATE_REASON_SUPPLICANT_TIMEOUT :
-- 
1.8.1.4

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: PppStats signal equivalent in NM-0.9

[Daniel Drake]

On Tue, Dec 11, 2012 at 9:46 AM, Daniel Drake  wrote:
> I can't see an equivalent in NetworkManager-0.9. Is there one, or an
> alternative way of getting such info?

Not at the moment, by the looks of things. Found
https://bugzilla.gnome.org/show_bug.cgi?id=661808
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

PppStats signal equivalent in NM-0.9

[Daniel Drake]

Hi,

NetworkManager-0.8 had a PppStats signal on the
org.freedesktop.NetworkManager.Device.Serial interface to show total
TX/RX bytes. Sugar used this to show bandwidth usage counters - quite
useful in the kinds of environments where modems might be used on OLPC
laptops (expensive bandwidth costs).

I can't see an equivalent in NetworkManager-0.9. Is there one, or an
alternative way of getting such info?

Thanks
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] core: don't activate uninitialized devices from udev

[Daniel Drake]

When enumerating devices, libgudev's matching by default will return
devices which udev has not yet finished initializing.

This was frequently causing boot-time races on the OLPC XO, where
NetworkManager would bring a device up before udev had renamed it,
causing the later rename to fail.

To solve this, filter the enumeration matches to only include
initialized devices. The devices that are present but uninitialized
at this time will arrive a short time later, via a uevent.

https://bugs.freedesktop.org/show_bug.cgi?id=56929
---
 src/nm-udev-manager.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/nm-udev-manager.c b/src/nm-udev-manager.c
index 792e53b..60f41aa 100644
--- a/src/nm-udev-manager.c
+++ b/src/nm-udev-manager.c
@@ -515,25 +515,35 @@ void
 nm_udev_manager_query_devices (NMUdevManager *self)
 {
NMUdevManagerPrivate *priv = NM_UDEV_MANAGER_GET_PRIVATE (self);
+   GUdevEnumerator *enumerator;
GList *devices, *iter;
 
g_return_if_fail (self != NULL);
g_return_if_fail (NM_IS_UDEV_MANAGER (self));
 
-   devices = g_udev_client_query_by_subsystem (priv->client, "net");
+   enumerator = g_udev_enumerator_new (priv->client);
+   g_udev_enumerator_add_match_subsystem (enumerator, "net");
+   g_udev_enumerator_add_match_is_initialized (enumerator);
+
+   devices = g_udev_enumerator_execute (enumerator);
for (iter = devices; iter; iter = g_list_next (iter)) {
net_add (self, G_UDEV_DEVICE (iter->data));
g_object_unref (G_UDEV_DEVICE (iter->data));
}
g_list_free (devices);
+   g_object_unref (enumerator);
 
 
-   devices = g_udev_client_query_by_subsystem (priv->client, "atm");
+   enumerator = g_udev_enumerator_new (priv->client);
+   g_udev_enumerator_add_match_subsystem (enumerator, "atm");
+   g_udev_enumerator_add_match_is_initialized (enumerator);
+   devices = g_udev_enumerator_execute (enumerator);
for (iter = devices; iter; iter = g_list_next (iter)) {
adsl_add (self, G_UDEV_DEVICE (iter->data));
g_object_unref (G_UDEV_DEVICE (iter->data));
}
g_list_free (devices);
+   g_object_unref (enumerator);
 }
 
 static void
-- 
1.7.11.7

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] olpc-mesh: force use of WEXT

[Daniel Drake]

The libertas driver now uses nl80211 for mesh, and wifi-utils chooses to
use wifi-utils-nl80211.

The wifi-utils-nl80211 code does not have implementations for
mesh_get_channel/mesh_set_channel and this breaks mesh networking.
Adding these methods under nl80211 is a little painful.

For now, force use of wifi-utils-wext to restore mesh networking.
---
 src/nm-device-olpc-mesh.c |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

I have written a set_mesh_channel implementation for nl80211 which
I think should work.

However, get_mesh_channel is harder: reading of the active channel in
nl80211 is done by reading scan results and looking for the network that
is marked as connected. The mesh device doesn't return scan results.

I think we could improve libertas to return always return a fake scan
result on the mesh device (with the expected SSID and channel details),
and also make it report itself as always connected.

Until I find a moment to try that approach, is this patch acceptable?

diff --git a/src/nm-device-olpc-mesh.c b/src/nm-device-olpc-mesh.c
index f6390c1..8e3cb95 100644
--- a/src/nm-device-olpc-mesh.c
+++ b/src/nm-device-olpc-mesh.c
@@ -55,6 +55,9 @@
 #include "nm-manager.h"
 #include "nm-enum-types.h"
 #include "wifi-utils.h"
+#if HAVE_WEXT
+#include "wifi-utils-wext.h"
+#endif
 
 /* This is a bug; but we can't really change API now... */
 #include "NetworkManagerVPN.h"
@@ -153,9 +156,16 @@ constructor (GType type,
nm_device_get_iface (NM_DEVICE (self)),
nm_device_get_ifindex (NM_DEVICE (self)));
 
-   priv->wifi_data = wifi_utils_init (nm_device_get_iface (NM_DEVICE 
(self)),
-  nm_device_get_ifindex (NM_DEVICE 
(self)),
-  FALSE);
+   /*
+* The kernel driver now uses nl80211, but we force use of WEXT because
+* the cfg80211 interactions are not quite ready to support access to
+* mesh control through nl80211 just yet.
+*/
+#if HAVE_WEXT
+   priv->wifi_data = wifi_wext_init (nm_device_get_iface (NM_DEVICE 
(self)),
+ nm_device_get_ifindex (NM_DEVICE 
(self)),
+ FALSE);
+#endif
if (priv->wifi_data == NULL) {
nm_log_warn (LOGD_HW | LOGD_OLPC_MESH, "(%s): failed to 
initialize WiFi driver",
 nm_device_get_iface (NM_DEVICE (self)));
-- 
1.7.10.1

___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-applet fails to compile against gnome-bluetooth-3.3

[Daniel Drake]

On Fri, Nov 25, 2011 at 9:10 AM, Daniel Drake  wrote:
> It looks like gnome-bluetooth used to specify dbus-glib includes/libs
> but no longer does so. Perhaps network-manager-applet compile should
> use the suggested includes of libnm-glib in this case.

Network-manager-applet does have this correct upstream, but in Fedora
as its built as a subpackage there is a hacky patch applied to enable
building of network-manager-applet before NetworkManager headers/libs
are fully installed on the build host. I updated this patch to pull in
dbus-glib-1 cflags/libs and now it is working.

Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

network-manager-applet fails to compile against gnome-bluetooth-3.3

[Daniel Drake]

Hi,

NetworkManager is breaking rawhide because it needs to be rebuilt
againts gnome-bluetooth-3.3. However, network-manager-applet fails to
rebuild:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
-DDATADIR=\"/usr/share\" -DICONDIR=\"\"
-DLOCALEDIR=\"/usr/share/locale\" -I../.. -I../../src/marshallers
-I../../src/utils -I../../src/libnm-gtk -I../../../include
-I../../../libnm-util -I../../../libnm-glib -pthread
-I/usr/include/gnome-bluetooth -I/usr/include/gtk-3.0
-I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng15 -Wall -Werror -std=gnu89 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables -Wshadow -Wmissing-declarations
-Wmissing-prototypes -Wno-deprecated-declarations
-Wno-error=deprecated-declarations -Wdeclaration-after-statement
-Wfloat-equal -Wno-unused-parameter -Wno-sign-compare
-fno-strict-aliasing -c bt-widget.c  -fPIC -DPIC -o .libs/bt-widget.o
In file included from bt-widget.c:45:0:
../../../libnm-glib/nm-remote-settings.h:28:28: fatal error:
dbus/dbus-glib.h: No such file or directory

It looks like gnome-bluetooth used to specify dbus-glib includes/libs
but no longer does so. Perhaps network-manager-applet compile should
use the suggested includes of libnm-glib in this case.

Thanks
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: SecretAgent.GetSecrets() return value

[Daniel Drake]

On Tue, Sep 6, 2011 at 11:20 PM, Dan Williams  wrote:
> Like you say if a secret is wrong or needs to be changed, there's no
> facility to ask for that secret.  We can (and should) make sure NM would
> fail the connection with a NM_DEVICE_REASON_NO_SECRETS or something like
> that if NM can find out the secrets are wrong, which could trigger the
> applet to toss up the "your connection failed, please re-enter your PSK"
> dialog or whatever.
>
> Or, if you use a secret agent, NM will ask for the secrets when it
> thinks it needs them.

I think I'll go with the secret agent option for now, as it doesn't
require immediate NM work, and as you say, it is quite easy to morph
the NM-0.8 implementation into a SecretAgent, and it really doesn't
need much code (only GetSecrets). I think this may even be the more
simplistic option, as it offloads all the tricky "do I need secrets
right now?" logic to NM.

> Return value should be a hash table of hash tables (basically an
> NMConnection of only the secrets), so for example if you're returning a
> WPA-PSK connection's secrets, it would be simply:
>
> wsec = { 'psk': 'some-really-secure-psk' }
> hash = { '802-11-wireless-security': wsec }
> return hash

Thanks for the clarification.

What would happen if a WEP connection was originally added with
auth-alg='open', but then in my GetSecrets response, I give:

wsec = { 'wep-key0': 'some-unsecure-key', 'auth-alg': 'shared' }
hash = { '802-11-wireless-security': wsec }

Would NM then use shared or open authentication?
('shared' is what would be desired, for the context of this see
http://mail.gnome.org/archives/networkmanager-list/2009-December/msg00018.html
)

Thanks,
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: SecretAgent.GetSecrets() return value

[Daniel Drake]

On Tue, Sep 6, 2011 at 10:54 PM, Dan Williams  wrote:
> Not sure I follow this...  you shouldn't need a secret agent if all that
> the UI is doing is Update() and AddConnection().  A secret agent is only
> required if there are any agent-provided secrets (ie, some secret has
> the flag AGENT_OWNED).  If you let NM handle all secrets then no secret
> agent should be required; initial secrets get to NM via the
> Connection.Update() call, which shouldn't require a secret agent (as
> long as all secrets are not AGENT_OWNED).

The way I've implemented it at the moment is (I think) the same as
nm-applet. I implement the SecretAgent interface, but I don't set any
special flags, so the secrets do get stored by NM.

However, the first time a connection is established, NetworkManager
needs to communicate the need for secrets, Sugar then needs to request
the info from the user and communicate it to NM. I implemented
SecretAgent for that purpose, and it is working.

I think you might be suggesting that before activating a connection,
Sugar somehow queries NM to see if secrets are present, and if they
aren't, it pops up a dialog requesting them, then it modifies the
connection to add the secrets, then it activates it?

It seems roundabout but it might work, but I wonder what happens when
the secrets are wrong or the password has changed, and the user needs
to be prompted? Seems like impementing SecretAgent (for the purpose of
prompting the user when the user needs to be prompted, not for the
purpose of actually storing secrets) would smooth out those corner
cases, and it looks like nm-applet works this way.

Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: SecretAgent.GetSecrets() return value

[Daniel Drake]

On Sun, Sep 4, 2011 at 8:12 PM, Sascha Silbe  wrote:
> I'd argue that Sugar shouldn't store the secrets at all but rather let
> NetworkManager take care of that.

I agree, and this is exactly how my code works. That is unrelated to
the issue at hand. A SecretAgent implementation is still required for
telling NM those secrets in the first place, so the question still
stands.

Thanks,
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

SecretAgent.GetSecrets() return value

[Daniel Drake]

Hi,

I'm working on finally porting Sugar to NetworkManager-0.9 and I have
a query regarding the SecretAgent implementation.
The docs here 
http://projects.gnome.org/NetworkManager/developers/api/09/ref-migrating.html#id565317
have a link to org.freedesktop.NetworkManager.SecretAgent but this
link is broken - I can't find any documentation for this interface.

Anyway, through some experimentation I see that GetSecrets() gets
given the entire settings collection for the connection where secrets
are needed. My question is: exactly what should be returned?

In the NM-0.8 secrets-getting scheme, we were advised to take the
entire settings object, add in the secrets, and send the whole thing
back:
http://mail.gnome.org/archives/networkmanager-list/2009-December/msg00018.html

However, if I do that with NM-0.9, with my GetSecrets call therefore
returning a complete settings collection including settings for
802-11-wireless, connection, ipv6, ipv4, and 802-11-wireless-security,
syslog shows NetworkManager complaining:

  NetworkManager[1748]: get_secret_flags: assertion `is_secret_prop
(setting, secret_name, error)' failed

The secrets do get communicated successfully, but it would be nice to
know what I'm doing wrong.

Thanks,
Daniel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] libnm-glib: allow NMRemoteSettings constructor with NULL bus

[Daniel Drake]

NMRemoteSettings's constructor requires a DBusGConnection, but there
currently aren't any usable gobject-introspection bindings for that class.
This means that NMRemoteSettings can't be used over gobject-introspection.

Move the default fallback to the system bus into the constructor path, so
that introspection bindings are usable.

Python test case:
from gi.repository import NMClient
NMClient.RemoteSettings()

Before, this produced a segfault. Now it returns a usable RemoteSettings
object.

Index: NetworkManager-0.8.9997/libnm-glib/nm-remote-settings.c
===
--- NetworkManager-0.8.9997.orig/libnm-glib/nm-remote-settings.c
+++ NetworkManager-0.8.9997/libnm-glib/nm-remote-settings.c
@@ -736,9 +736,6 @@ get_all_cb  (DBusGProxy *proxy,
 NMRemoteSettings *
 nm_remote_settings_new (DBusGConnection *bus)
 {
-   if (bus == NULL)
-   bus = dbus_g_bus_get (DBUS_BUS_SYSTEM, NULL);
-
return (NMRemoteSettings *) g_object_new (NM_TYPE_REMOTE_SETTINGS,
  NM_REMOTE_SETTINGS_BUS, bus,
  NULL);
@@ -887,11 +884,15 @@ set_property (GObject *object, guint pro
   const GValue *value, GParamSpec *pspec)
 {
NMRemoteSettingsPrivate *priv = NM_REMOTE_SETTINGS_GET_PRIVATE (object);
+   DBusGConnection *connection;
 
switch (prop_id) {
case PROP_BUS:
/* Construct only */
-   priv->bus = dbus_g_connection_ref ((DBusGConnection *) 
g_value_get_boxed (value));
+   connection = (DBusGConnection *) g_value_get_boxed (value);
+   if (!connection)
+   connection = dbus_g_bus_get (DBUS_BUS_SYSTEM, NULL);
+   priv->bus = dbus_g_connection_ref (connection);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NMDeviceWifi "scanning" notifier inaccurate

[Daniel Drake]

Bump :)

On 9 July 2010 15:58, Daniel Drake  wrote:
> I finally got round to investigating this issue:
> http://thread.gmane.org/gmane.linux.network.networkmanager.devel/13607
>
> To summarize, notifications of the "scanning" property of NMDeviceWifi
> are not always generated when reading this value would in fact produce
> a different value from before.
>
> This property is implemented as a call to
> nm_supplicant_interface_get_scanning() which is implemented as "return
> TRUE if the supplicant state is scanning, or if the supplicant
> asserted the flag saying that scanning is in-progress"
>
> When the supplicant asserts/deasserts the "scanning" flag, we
> correctly arrive in supplicant_iface_notify_scanning_cb() which
> generates a notification on the property. The bug is that NMDeviceWifi
> doesn't watch for relevant changes in the supplicant state to generate
> the notification in the other cases when this property can change
> value.
>
> The bug I'm seeing is:
> 1. eth0 is scanning, so the supplicant state is: scanning=1 state=scanning
>
> 2. I activate a connection on msh0. real_act_stage1_prepare() in the
> mesh device realizes that the companion is scanning so it returns
> NM_ACT_STAGE_RETURN_POSTPONE
> The driver is listening for changes in the NMDeviceWifi scanning
> property so that it can continue the state progression of msh0.
>
> 3. supplicant state changes to: scanning=0 state=scanning
> The "notify" event is generated on NMDeviceWifi but the scanning
> property still reads false so nothing interesting happens.

This is supposed to say "still reads true"

> 4. supplicant state changse to: scanning=0 state=disconnected
> At this point no notify event is generated, but it should be, because
> reading NMDeviceWifi's scanning property will now finally read FALSE.
>
>
> I'm attaching a patch that fixes the issue. It will generate a few
> more notify events than needed (i.e. it will sometimes notify when no
> property change happened) but I can't think of a nice way to make this
> more accurate. What do you think?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

NMDeviceWifi "scanning" notifier inaccurate

[Daniel Drake]

Hi Dan,

I finally got round to investigating this issue:
http://thread.gmane.org/gmane.linux.network.networkmanager.devel/13607

To summarize, notifications of the "scanning" property of NMDeviceWifi
are not always generated when reading this value would in fact produce
a different value from before.

This property is implemented as a call to
nm_supplicant_interface_get_scanning() which is implemented as "return
TRUE if the supplicant state is scanning, or if the supplicant
asserted the flag saying that scanning is in-progress"

When the supplicant asserts/deasserts the "scanning" flag, we
correctly arrive in supplicant_iface_notify_scanning_cb() which
generates a notification on the property. The bug is that NMDeviceWifi
doesn't watch for relevant changes in the supplicant state to generate
the notification in the other cases when this property can change
value.

The bug I'm seeing is:
1. eth0 is scanning, so the supplicant state is: scanning=1 state=scanning

2. I activate a connection on msh0. real_act_stage1_prepare() in the
mesh device realizes that the companion is scanning so it returns
NM_ACT_STAGE_RETURN_POSTPONE
The driver is listening for changes in the NMDeviceWifi scanning
property so that it can continue the state progression of msh0.

3. supplicant state changes to: scanning=0 state=scanning
The "notify" event is generated on NMDeviceWifi but the scanning
property still reads false so nothing interesting happens.

4. supplicant state changse to: scanning=0 state=disconnected
At this point no notify event is generated, but it should be, because
reading NMDeviceWifi's scanning property will now finally read FALSE.


I'm attaching a patch that fixes the issue. It will generate a few
more notify events than needed (i.e. it will sometimes notify when no
property change happened) but I can't think of a nice way to make this
more accurate. What do you think?

Thanks,
Daniel
Index: NetworkManager-0.7.2.997/src/nm-device-wifi.c
===
--- NetworkManager-0.7.2.997.orig/src/nm-device-wifi.c
+++ NetworkManager-0.7.2.997/src/nm-device-wifi.c
@@ -2389,6 +2389,8 @@ supplicant_iface_connection_state_cb_han
}
 
 out:
+   if (task->new_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING || 
task->old_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING)
+   g_object_notify (G_OBJECT (self), "scanning");
finish_supplicant_task (task, FALSE);
return FALSE;
 }
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: long delay for scan results after suspend

[Daniel Drake]

On Thu, 2009-12-10 at 16:22 +, Daniel Drake wrote:
> With the new OLPC XO-1.5, our kernel driver fully powers down the
> wireless device during suspend to the point where the kernel thinks the
> SDIO card has been ejected.
> 
> It immediately comes back on resume, but there is a delay of
> approximately 20 seconds before NM offers scan results to Sugar, which
> is frustratingly long.

The delay isn't quite so severe, at least for me. I think we may have
been seeing other problems.

However, we do still face a 4-5 second delay due to constructor() in
nm-device.c:

/* Delay transition from UNMANAGED to UNAVAILABLE until we've given the
 * system settings service a chance to figure out whether the device is
 * managed or not.
 */
priv->start_timer = g_timeout_add_seconds (4, device_start, dev);

Can we do better than that? For an aggressive-suspend setup like ours,
having to wait this long for networks to crop up again is quite harmful
to the user experience.

And just out of curiosity, is this any better in 0.8? I can see that the
code has moved around quite a bit.

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

[Daniel Drake]

On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote:
> What would you expect the routing table to look like in your case?  I
> suppose we could do a default route for link-local.  Not sure if that
> will confuse apps that expect a default route to mean an internet
> connection though.

I would expect the subnet route, as NM is creating already:
dest=169.254.0.0
gateway=0.0.0.0
genmask=255.255.0.0

I would also like the routing table to either include a default route:
dest=0.0.0
gateway=0.0.0.0
genmask=0.0.0.0

or a multicast one:
dest=224.0.0.0
gateway=0.0.0.0
genmask=240.0.0.0

The routing table that NM is setting up now is reasonable, in my
opinion, but there should be some way of customizing the behaviour in
the settings object.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

[Daniel Drake]

On Wed, 2009-12-16 at 17:22 -0800, Dan Williams wrote:
> The default route is controlled internally by NM; it should never be
> part of the connection settings.  Does your multicast routing need to be
> different than the default route?

There is no default route created for link-local connections. And if
there were, I suspect this isn't always what you want, e.g. see
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/99489

However, if the default route was created, I'd be happy and our bug
would go away. There would be no need to create a multicast route. (I
was just taking that approach as thats what happens when Sugar/NM-0.6
creates a simple mesh connection on XO-1 -- there is no default route,
but there is a multicast route)

You can reproduce this easily - just use nm-applet to create a
link-local adhoc wireless connection, run "route -n", and observe a lack
of default route.

I've found the piece of code that causes the routes property to be
ignored for link-local connections, it's in
real_act_stage4_get_ip4_config()

We either need to rework that code to allow certain types of routes, or
get that default route created like you say. What do you think?

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

[Daniel Drake]

On Wed, 2009-12-16 at 11:59 -0800, Dan Williams wrote:
> Yes, it's correct in these cases because for shared, NM is handling the
> network and there's no routing out of it since the network is NAT-ed to
> the main connection.  In link-local it's not relevant since the
> link-local is by definition /not routable/...

But just because there is no upstream router doesn't mean that access to
the routing table should be excluded. The user may want to add a default
route out on that interface. Or, in our case, we want to pass all
multicast traffic to the interface.

> I'm more inclined to think that the bits aren't getting passed by to NM
> correctly; are you sure you're passing the item with a dbus signature of
> 'aau'?  The code that actually unpacks the routes property is
> nm_utils_ip4_routes_from_gvalue() in nm-utils.c.  Trace into
> nm-setting-ip4-config.c's set_property() call and see if the PROP_ROUTES
> case is run.

set_property() was never called but I figured it out: I have to use
dbus.Array() in Python.

I'm now using:

ip4_config['routes'] = dbus.Array([(224,4,0,0)], signature='au')

set_property() is now being called for routes, but the routing table is
not being modified. I'll continue investigating tomorrow.

Thanks for your help, as always!
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

[Daniel Drake]

On Wed, 2009-12-16 at 17:53 +, Daniel Drake wrote:
> Thanks! Very comprehensive.
> 
> Is this part correct?
> 
> "Routes cannot be used with the 'shared' or 'link-local' methods as
> there is no upstream network."
> 
> We're using link-local. Might explain my troubles, but in this case we
> need a route even though we aren't dealing with an upstream network.

Well, if it is correct, we aren't even hitting the bit of the code where
it is enforced. (or at least I haven't spotted it)

I have traced the code and I am finding :

- nm_setting_new_from_hash() is being called 
- it is calling parse_one_setting()
- which then calls nm_setting_new_from_hash()
- the hash table has 2 properties inside(method,routes)
- one_property_cb() is called on both those properties and is successful
at adding them to the list
- back in nm_setting_new_from_hash(), g_object_newv() is called with the
property list (method and routes)
- a NMSettingIP4Config is constructed, and these properties are set:
 6(ignore auto routes), 7(ignore auto dns), 10(never default), 1(method)

Why is set_property not called for the routes property?
Is it because routes is a _nm_param_spec_specialized? (I'm not exactly
sure what the difference is between this and the regular glib param
specs)

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

[Daniel Drake]

On Wed, 2009-12-16 at 09:49 -0800, Dan Williams wrote:
> http://live.gnome.org/NetworkManager
> 
> which leads you to:
> 
> http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html
> 

Thanks! Very comprehensive.

Is this part correct?

"Routes cannot be used with the 'shared' or 'link-local' methods as
there is no upstream network."

We're using link-local. Might explain my troubles, but in this case we
need a route even though we aren't dealing with an upstream network.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

[Daniel Drake]

On Wed, 2009-12-16 at 12:40 +, Daniel Drake wrote:
> Hi,
> 
> Ad-hoc networking is broken in Sugar because no route is created for
> multicast packets - this means the collaboration features do not work.
> 
> I can see that I can specify routes in the IP4Config object 

I started guessing at some numbers and actually, I can't seem to get
this working at all.

With my latest guess, here is the object being returned by
NMSettingsConnection.GetSettings() on the user settings service:

{'802-11-wireless': {'band': 'bg', 'ssid': dbus.ByteArray("asfdsfg's
network"), 'mode': 'adhoc'}, 'connection': {'autoconnect': False,
'type': '802-11-wireless', 'id': "Auto asfdsfg's network", 'uuid':
'28cbb90800f37c775511a1eab45a834b53cb32a1'}, 'ipv4': {'routes': [[224,
4, 0, 0]], 'method': 'link-local'}}

There is no resulting entry in the routing table (checked by running
'route -n')

Even if I use an invalid value (such as a string) for routes, NM doesn't
complain, as if it is ignoring my routes key altogether. Am I missing
something obvious?

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

IP4Config and routes

[Daniel Drake]

Hi,

Ad-hoc networking is broken in Sugar because no route is created for
multicast packets - this means the collaboration features do not work.

I can see that I can specify routes in the IP4Config object (hence we
could modify Sugar to fix this) but the only documentation I can find
is:

Routes - aau - (read)
Tuples of IPv4 route/prefix/next-hop/metric.

I'm not too knowledgeable about routing tables and the language I speak
is the one that "route -n" returns, basically I want a route of:
destination=224.0.0.0
gateway=0.0.0.0
genmask=240.0.0.0
flags=U
metric=0

I guess next-hop is gateway, and metric is metric, but I'm a bit stuck
on "route" and "prefix"

Can anyone help me convert those values into ones that NM understands,
or point me at some existing code which uses this functionality?

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

long delay for scan results after suspend

[Daniel Drake]

Hi,

With the new OLPC XO-1.5, our kernel driver fully powers down the
wireless device during suspend to the point where the kernel thinks the
SDIO card has been ejected.

It immediately comes back on resume, but there is a delay of
approximately 20 seconds before NM offers scan results to Sugar, which
is frustratingly long.

When is NM expected to perform scans in this situation?

It is possible that the libertas wifi driver is taking this long to
deliver results although it seems unlikely.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: specifying shared key authentication in the secrets response

[Daniel Drake]

On Wed, 2009-12-02 at 13:50 -0800, Dan Williams wrote:
> We could do that; but NM already has some logic for this.  If you pass
> back the *complete* wireless-security setting, NM will use that instead.
> NM first tries to validate the entire NMSettingWirelessSecurity (using
> nm_setting_verify) and if that fails, will just extract the returned
> secrets.

Thanks! This indeed solves the problem.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

specifying shared key authentication in the secrets response

[Daniel Drake]

Hi,

I'm working on a bug in Sugar: you can't connect to shared key WEP
networks. http://dev.sugarlabs.org/ticket/1602

The problem is that sugar's settings service implementation offers the
connection to NM and activates it, but at this point in the settings it
sends:
'802-11-wireless-security': {'key-mgmt': 'none'}

Then NM runs around a bit and sends a secrets request. Sugar pops up a
key-entry dialog. This is the first point in the current sugar UI design
where you can choose between open or shared key. I select shared key,
enter the key, and sugar sends the secrets response:

{'802-11-wireless-security': {'auth-alg': 'shared', 'wep-key0':
'12'}}

However at this point, NM seems to ignore the 'auth-alg' selection.
Experimentation shows that if I specify the shared auth-alg in the
initial Settings announcement it works fine.

Would it be difficult to improve NM so that it could accept the auth-alg
at this later stage? Or do we need to redesign Sugar's UI to fix this,
so that Sugar knows of the user's open vs shared preference earlier on?

cheers
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: OLPC mesh support backported to NM-0.7

[Daniel Drake]

On Wed, 2009-11-25 at 12:29 -0800, Dan Williams wrote:

> > Once we're at that point I'd be interested in getting them included in
> > Fedora 11 for the community-maintained XO-1 distro. How do you feel
> > about that?
> 
> I'll have to trawl through and find a few fixes I did for the mesh stuff
> in master and cherry-pick those back to stable too unless you get there
> first.

Thanks for the fixes, hadn't spotted them. 
Yeah I can do that. So are you happy for me to backport and push all
those patches to 0.7 branch now?

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: OLPC mesh support backported to NM-0.7

[Daniel Drake]

Hi Dan,

On Wed, 2009-10-07 at 10:32 -0700, Dan Williams wrote:
> Too close to 0.7.2, but I was going to commit them to a 0.7.x branch and
> integrate them after a 0.7.2 release, which I keep saying I'll do but
> then never quite do.

I see you just released 0.7.2, congrats!
Can these patches go in now, please?

Once we're at that point I'd be interested in getting them included in
Fedora 11 for the community-maintained XO-1 distro. How do you feel
about that?

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

which AccessPoint to activate?

[Daniel Drake]

Hi,

I'm working on some improvements to Sugar's network view...
We are now using logic similar to that found in nm-applet in order to
group access points into networks, and then we only show 1 entry per
network.

I'm looking at org.freedesktop.NetworkManager.ActivateConnection():
http://projects.gnome.org/NetworkManager/developers/spec.html#org.freedesktop.NetworkManager

That function takes an AccessPoint as the final parameter
(specific_object).

For networks with more than 1 AP, does it matter which AccessPoint is
passed as that final parameter? Should we pick the one with the highest
signal strength or something like that?

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: OLPC mesh support backported to NM-0.7

[Daniel Drake]

2009/9/18 Daniel Drake :
> Hi Dan,
>
> I'm sending you 6 patches which backport the NM mesh support to the
> v0.7 branch. They are all direct backports from the patches you
> committed to master, with only the minimal changes needed to get
> things working on 0.7. I've tested it with my modified Sugar and it is
> working well.

ping.. any thoughts on these patches?

Thanks!
Daniel
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH v0.7 6/6] olpc: add mesh device logic and config setting

[Daniel Drake]

diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index d61a89c..ce54111 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -75,7 +75,8 @@ typedef enum NMDeviceType
NM_DEVICE_TYPE_ETHERNET,
NM_DEVICE_TYPE_WIFI,
NM_DEVICE_TYPE_GSM,
-   NM_DEVICE_TYPE_CDMA
+   NM_DEVICE_TYPE_CDMA,
+   NM_DEVICE_TYPE_OLPC_MESH = 6,
 } NMDeviceType;
 
 /* DEPRECATED TYPE NAMES */
diff --git a/introspection/Makefile.am b/introspection/Makefile.am
index a77dba1..671945f 100644
--- a/introspection/Makefile.am
+++ b/introspection/Makefile.am
@@ -5,6 +5,7 @@ EXTRA_DIST = \
vpn-errors.xml \
nm-access-point.xml \
nm-device-wifi.xml \
+   nm-device-olpc-mesh.xml \
nm-device-ethernet.xml \
nm-device-cdma.xml \
nm-device-gsm.xml \
diff --git a/introspection/nm-device-olpc-mesh.xml 
b/introspection/nm-device-olpc-mesh.xml
new file mode 100644
index 000..7d326b6
--- /dev/null
+++ b/introspection/nm-device-olpc-mesh.xml
@@ -0,0 +1,32 @@
+
+
+http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0";>
+  
+
+  
+The hardware address of the device.
+  
+
+
+  
+The object path of the companion device.
+  
+
+
+  
+The currently active channel.
+  
+
+
+
+
+
+A dictionary containing the FIXME: check changed parameters.
+
+
+
+Emitted when the wireless device's properties changed.
+
+
+  
+
diff --git a/libnm-util/Makefile.am b/libnm-util/Makefile.am
index 225d4b5..caadc1d 100644
--- a/libnm-util/Makefile.am
+++ b/libnm-util/Makefile.am
@@ -21,6 +21,7 @@ libnm_util_include_HEADERS =  \
nm-setting-serial.h \
nm-setting-gsm.h\
nm-setting-cdma.h   \
+   nm-setting-olpc-mesh.h  \
nm-setting-wired.h  \
nm-setting-wireless.h   \
nm-setting-wireless-security.h  \
@@ -43,6 +44,7 @@ libnm_util_la_SOURCES=\
nm-setting-serial.c \
nm-setting-gsm.c\
nm-setting-cdma.c   \
+   nm-setting-olpc-mesh.c  \
nm-setting-wired.c  \
nm-setting-wireless.c   \
nm-setting-wireless-security.c  \
diff --git a/libnm-util/libnm-util.ver b/libnm-util/libnm-util.ver
index 9fdc235..30a63e6 100644
--- a/libnm-util/libnm-util.ver
+++ b/libnm-util/libnm-util.ver
@@ -246,6 +246,10 @@ global:
nm_setting_wireless_security_remove_pairwise;
nm_setting_wireless_security_remove_proto;
nm_setting_wireless_security_set_wep_key;
+   nm_setting_olpc_mesh_get_type;
+   nm_setting_olpc_mesh_get_ssid;
+   nm_setting_olpc_mesh_get_channel;
+   nm_setting_olpc_mesh_get_dhcp_anycast_address;
nm_utils_deinit;
nm_utils_escape_ssid;
nm_utils_gvalue_hash_dup;
diff --git a/libnm-util/nm-connection.c b/libnm-util/nm-connection.c
index ba1685a..ef84e34 100644
--- a/libnm-util/nm-connection.c
+++ b/libnm-util/nm-connection.c
@@ -40,6 +40,7 @@
 #include "nm-setting-wireless.h"
 #include "nm-setting-wireless-security.h"
 #include "nm-setting-vpn.h"
+#include "nm-setting-olpc-mesh.h"
 
 #include "nm-setting-serial.h"
 #include "nm-setting-gsm.h"
@@ -215,6 +216,11 @@ register_default_settings (void)
  NM_SETTING_WIRELESS_ERROR,
  1);
 
+   register_one_setting (NM_SETTING_OLPC_MESH_SETTING_NAME,
+ NM_TYPE_SETTING_OLPC_MESH,
+ NM_SETTING_OLPC_MESH_ERROR,
+ 1);
+
register_one_setting (NM_SETTING_GSM_SETTING_NAME,
  NM_TYPE_SETTING_GSM,
  NM_SETTING_GSM_ERROR,
diff --git a/libnm-util/nm-setting-olpc-mesh.c 
b/libnm-util/nm-setting-olpc-mesh.c
new file mode 100644
index 000..dd0e1d6
--- /dev/null
+++ b/libnm-util/nm-setting-olpc-mesh.c
@@ -0,0 +1,265 @@
+/* -*- Mode: C; tab-width: 5; indent-tabs-mode: t; c-basic-offset: 5 -*- */
+
+/*
+ * Dan Williams 
+ * Tambet Ingo 
+ * Sjoerd Simons 
+ * Daniel Drake 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License a

[PATCH v0.7 5/6] core: allow devices to suppress other device's autoconnect

[Daniel Drake]

This allows a device (or a companion) to signal that it is not a good
time for a specific device to autoconnect to a network.

The OLPC mesh device will use this to prevent automatic connection
to WLAN networks while the mesh device is active.
---
 src/NetworkManagerPolicy.c |2 +-
 src/nm-device.c|   45 
 src/nm-device.h|1 +
 3 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/src/NetworkManagerPolicy.c b/src/NetworkManagerPolicy.c
index 6bba92f..e2d4c95 100644
--- a/src/NetworkManagerPolicy.c
+++ b/src/NetworkManagerPolicy.c
@@ -726,7 +726,7 @@ schedule_activate_check (NMPolicy *policy, NMDevice *device)
if (state < NM_DEVICE_STATE_DISCONNECTED)
return;
 
-   if (!nm_device_can_activate (device))
+   if (!nm_device_can_activate (device) || !nm_device_autoconnect_allowed 
(device))
return;
 
for (iter = policy->pending_activation_checks; iter; iter = 
g_slist_next (iter)) {
diff --git a/src/nm-device.c b/src/nm-device.c
index 046e795..7adbfdb 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -50,6 +50,7 @@
 #include "nm-setting-connection.h"
 #include "nm-dnsmasq-manager.h"
 #include "nm-dhcp4-config.h"
+#include "nm-marshal.h"
 
 #define NM_ACT_REQUEST_IP4_CONFIG "nm-act-request-ip4-config"
 
@@ -60,6 +61,13 @@ G_DEFINE_TYPE_EXTENDED (NMDevice, nm_device, G_TYPE_OBJECT,
G_IMPLEMENT_INTERFACE 
(NM_TYPE_DEVICE_INTERFACE,

   device_interface_init))
 
+enum {
+   AUTOCONNECT_ALLOWED,
+   LAST_SIGNAL,
+};
+
+static guint signals[LAST_SIGNAL] = { 0 };
+
 #define NM_DEVICE_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE ((o), 
NM_TYPE_DEVICE, NMDevicePrivate))
 
 struct _NMDevicePrivate
@@ -363,6 +371,34 @@ nm_device_can_activate (NMDevice *self)
return TRUE;
 }
 
+static gboolean
+autoconnect_allowed_accumulator (GSignalInvocationHint *ihint,
+ GValue *return_accu,
+ const GValue *handler_return, gpointer data)
+{
+   if (!g_value_get_boolean (handler_return))
+   g_value_set_boolean (return_accu, FALSE);
+   return TRUE;
+}
+
+gboolean
+nm_device_autoconnect_allowed (NMDevice *self)
+{
+   GValue instance = { 0, };
+   GValue retval = { 0, };
+
+   g_value_init (&instance, G_TYPE_OBJECT);
+   g_value_take_object (&instance, self);
+
+   g_value_init (&retval, G_TYPE_BOOLEAN);
+   g_value_set_boolean (&retval, TRUE);
+
+   /* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
+* value being changed if no handlers are connected */
+   g_signal_emitv (&instance, signals[AUTOCONNECT_ALLOWED], 0, &retval);
+   return g_value_get_boolean (&retval);
+}
+
 NMConnection *
 nm_device_get_best_auto_connection (NMDevice *dev,
 GSList *connections,
@@ -2383,6 +2419,15 @@ nm_device_class_init (NMDeviceClass *klass)
g_object_class_override_property (object_class,
  
NM_DEVICE_INTERFACE_PROP_MANAGED,
  
NM_DEVICE_INTERFACE_MANAGED);
+
+   signals[AUTOCONNECT_ALLOWED] =
+   g_signal_new ("autoconnect-allowed",
+ G_OBJECT_CLASS_TYPE (object_class),
+ G_SIGNAL_RUN_LAST,
+ 0,
+ autoconnect_allowed_accumulator, NULL,
+ _nm_marshal_BOOLEAN__VOID,
+ G_TYPE_BOOLEAN, 0);
 }
 
 static gboolean
diff --git a/src/nm-device.h b/src/nm-device.h
index 05409b5..9fc53da 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -157,6 +157,7 @@ void
nm_device_activate_schedule_stage4_ip_config_timeout(NMDevice *device);
 gboolean   nm_device_deactivate_quickly(NMDevice *dev);
 gboolean   nm_device_is_activating (NMDevice *dev);
 gboolean   nm_device_can_interrupt_activation  
(NMDevice *self);
+gboolean   nm_device_autoconnect_allowed   (NMDevice *self);
 
 NMDeviceState nm_device_get_state (NMDevice *device);
 
-- 
1.6.4

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH v0.7 4/6] wifi: allow wifi scans to be inhibited by other devices

[Daniel Drake]

Like the OLPC mesh interface, which uses the same actual MAC & radio
as the OLPC wifi device, and thus when mesh is active the wifi
shouldn't be scanning.
---
 marshallers/nm-marshal.list |1 +
 src/nm-device-wifi.c|   43 ++-
 2 files changed, 43 insertions(+), 1 deletions(-)

diff --git a/marshallers/nm-marshal.list b/marshallers/nm-marshal.list
index ec3cf45..8e572d1 100644
--- a/marshallers/nm-marshal.list
+++ b/marshallers/nm-marshal.list
@@ -18,3 +18,4 @@ VOID:STRING,UINT
 VOID:OBJECT,OBJECT,ENUM
 VOID:POINTER,STRING
 POINTER:POINTER
+BOOLEAN:VOID
diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
index bf03bb7..10ce0b7 100644
--- a/src/nm-device-wifi.c
+++ b/src/nm-device-wifi.c
@@ -37,6 +37,7 @@
 #include "nm-device-interface.h"
 #include "nm-device-private.h"
 #include "nm-utils.h"
+#include "nm-marshal.h"
 #include "NetworkManagerUtils.h"
 #include "NetworkManagerPolicy.h"
 #include "nm-activation-request.h"
@@ -91,6 +92,7 @@ enum {
ACCESS_POINT_REMOVED,
HIDDEN_AP_FOUND,
PROPERTIES_CHANGED,
+   SCANNING_ALLOWED,
 
LAST_SIGNAL
 };
@@ -1682,13 +1684,43 @@ can_scan (NMDeviceWifi *self)
 }
 
 static gboolean
+scan_allowed_accumulator (GSignalInvocationHint *ihint,
+  GValue *return_accu,
+  const GValue *handler_return,
+  gpointer data)
+{
+   if (!g_value_get_boolean (handler_return))
+   g_value_set_boolean (return_accu, FALSE);
+   return TRUE;
+}
+
+static gboolean
+scan_allowed (NMDeviceWifi *self)
+{
+   GValue instance = { 0, };
+   GValue retval = { 0, };
+
+   g_value_init (&instance, G_TYPE_OBJECT);
+   g_value_take_object (&instance, self);
+
+   g_value_init (&retval, G_TYPE_BOOLEAN);
+   g_value_set_boolean (&retval, TRUE);
+
+   /* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
+* value being changed if no handlers are connected */
+   g_signal_emitv (&instance, signals[SCANNING_ALLOWED], 0, &retval);
+
+   return g_value_get_boolean (&retval);
+}
+
+static gboolean
 request_wireless_scan (gpointer user_data)
 {
NMDeviceWifi *self = NM_DEVICE_WIFI (user_data);
NMDeviceWifiPrivate *priv = NM_DEVICE_WIFI_GET_PRIVATE (self);
gboolean backoff = FALSE;
 
-   if (can_scan (self)) {
+   if (can_scan (self) && scan_allowed (self)) {
if (nm_supplicant_interface_request_scan 
(priv->supplicant.iface)) {
/* success */
backoff = TRUE;
@@ -3384,6 +3416,15 @@ nm_device_wifi_class_init (NMDeviceWifiClass *klass)
nm_properties_changed_signal_new (object_class,
  G_STRUCT_OFFSET 
(NMDeviceWifiClass, properties_changed));
 
+   signals[SCANNING_ALLOWED] =
+   g_signal_new ("scanning-allowed",
+ G_OBJECT_CLASS_TYPE (object_class),
+ G_SIGNAL_RUN_LAST,
+ 0,
+ scan_allowed_accumulator, NULL,
+ _nm_marshal_BOOLEAN__VOID,
+ G_TYPE_BOOLEAN, 0);
+
dbus_g_object_type_install_info (G_TYPE_FROM_CLASS (klass), 
&dbus_glib_nm_device_wifi_object_info);
 
dbus_g_error_domain_register (NM_WIFI_ERROR, NULL, NM_TYPE_WIFI_ERROR);
-- 
1.6.4

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH v0.7 3/6] core: allow devices to specify a DHCP anycast address

[Daniel Drake]

Relevant only for OLPC at this point; the mesh device uses it to
target DHCP requests at a pre-defined mesh portal anycast address.
---
 src/dhcp-manager/nm-dhcp-dhclient.c |   23 +++
 src/dhcp-manager/nm-dhcp-dhcpcd.c   |3 ++-
 src/dhcp-manager/nm-dhcp-manager.c  |5 +++--
 src/dhcp-manager/nm-dhcp-manager.h  |6 --
 src/nm-device.c |   32 +---
 src/nm-device.h |1 +
 6 files changed, 58 insertions(+), 12 deletions(-)

diff --git a/src/dhcp-manager/nm-dhcp-dhclient.c 
b/src/dhcp-manager/nm-dhcp-dhclient.c
index 81cecb6..691e129 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient.c
@@ -84,6 +84,7 @@ get_leasefile_for_iface (const char * iface, const char *uuid)
 static gboolean
 merge_dhclient_config (NMDHCPDevice *device,
NMSettingIP4Config *s_ip4,
+   guint8 *anycast_addr,
const char *contents,
const char *orig,
GError **error)
@@ -162,6 +163,17 @@ merge_dhclient_config (NMDHCPDevice *device,
g_string_append_printf (new_contents, 
DHCP_HOSTNAME_FORMAT "\n", tmp);
}
 
+   if (anycast_addr) {
+   g_string_append_printf (new_contents, "interface \"%s\" {\n"
+   " initial-interval 1; \n"
+   " anycast-mac ethernet 
%02x:%02x:%02x:%02x:%02x:%02x;\n"
+   "}\n",
+   device->iface,
+   anycast_addr[0], anycast_addr[1],
+   anycast_addr[2], anycast_addr[3],
+   anycast_addr[4], anycast_addr[5]);
+   }
+
if (g_file_set_contents (device->conf_file, new_contents->str, -1, 
error))
success = TRUE;
 
@@ -176,7 +188,9 @@ merge_dhclient_config (NMDHCPDevice *device,
  * config file along with the NM options.
  */
 static gboolean
-create_dhclient_config (NMDHCPDevice *device, NMSettingIP4Config *s_ip4)
+create_dhclient_config (NMDHCPDevice *device,
+NMSettingIP4Config *s_ip4,
+guint8 *dhcp_anycast_addr)
 {
char *orig = NULL, *contents = NULL;
GError *error = NULL;
@@ -216,7 +230,7 @@ create_dhclient_config (NMDHCPDevice *device, 
NMSettingIP4Config *s_ip4)
 
 out:
error = NULL;
-   if (merge_dhclient_config (device, s_ip4, contents, orig, &error))
+   if (merge_dhclient_config (device, s_ip4, dhcp_anycast_addr, contents, 
orig, &error))
success = TRUE;
else {
nm_warning ("%s: error creating dhclient configuration: %s",
@@ -242,7 +256,8 @@ dhclient_child_setup (gpointer user_data G_GNUC_UNUSED)
 GPid
 nm_dhcp_client_start (NMDHCPDevice *device,
   const char *uuid,
-  NMSettingIP4Config *s_ip4)
+  NMSettingIP4Config *s_ip4,
+  guint8 *dhcp_anycast_addr)
 {
GPtrArray *dhclient_argv = NULL;
GPid pid = 0;
@@ -266,7 +281,7 @@ nm_dhcp_client_start (NMDHCPDevice *device,
goto out;
}
 
-   if (!create_dhclient_config (device, s_ip4))
+   if (!create_dhclient_config (device, s_ip4, dhcp_anycast_addr))
goto out;
 
/* Kill any existing dhclient bound to this interface */
diff --git a/src/dhcp-manager/nm-dhcp-dhcpcd.c 
b/src/dhcp-manager/nm-dhcp-dhcpcd.c
index 05db9dd..a6ce8d2 100644
--- a/src/dhcp-manager/nm-dhcp-dhcpcd.c
+++ b/src/dhcp-manager/nm-dhcp-dhcpcd.c
@@ -62,7 +62,8 @@ dhcpcd_child_setup (gpointer user_data G_GNUC_UNUSED)
 GPid
 nm_dhcp_client_start (NMDHCPDevice *device,
   const char *uuid,
-  NMSettingIP4Config *s_ip4)
+  NMSettingIP4Config *s_ip4,
+  guint8 *dhcp_anycast_addr)
 {
GPtrArray *argv = NULL;
GPid pid = 0;
diff --git a/src/dhcp-manager/nm-dhcp-manager.c 
b/src/dhcp-manager/nm-dhcp-manager.c
index c5a6509..523a3ee 100644
--- a/src/dhcp-manager/nm-dhcp-manager.c
+++ b/src/dhcp-manager/nm-dhcp-manager.c
@@ -578,7 +578,8 @@ nm_dhcp_manager_begin_transaction (NMDHCPManager *manager,
const char *iface,
const char *uuid,
NMSettingIP4Config *s_ip4,
-   guint32 timeout)
+   guint32 timeout,
+   guint8 *dhcp_anycast_addr)
 {
NMDHCPManagerPrivate *priv;
NMDHCPDevice *device;
@@ -603,7 +604,7 @@ nm_dhcp_manager_begin_transaction (NMDHCPManager *manager,
nm_info ("Activation (%s) Beginning DHCP transaction (timeout in %d 
seconds)",
 iface, tim

[PATCH v0.7 2/6] core: allow device subclasses to override DHCP timeout

[Daniel Drake]

---
 src/dhcp-manager/nm-dhcp-manager.c |   12 ++--
 src/nm-device.c|   13 -
 src/nm-device.h|2 ++
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/src/dhcp-manager/nm-dhcp-manager.c 
b/src/dhcp-manager/nm-dhcp-manager.c
index faef79b..c5a6509 100644
--- a/src/dhcp-manager/nm-dhcp-manager.c
+++ b/src/dhcp-manager/nm-dhcp-manager.c
@@ -499,8 +499,7 @@ nm_dhcp_manager_handle_timeout (gpointer user_data)
 {
NMDHCPDevice *device = (NMDHCPDevice *) user_data;
 
-   nm_info ("Device '%s' DHCP transaction took too long (>%ds), stopping 
it.",
-device->iface, NM_DHCP_TIMEOUT);
+   nm_info ("(%s): DHCP transaction took too long, stopping it.", 
device->iface);
 
nm_dhcp_manager_cancel_transaction (device->manager, device->iface);
 
@@ -598,15 +597,16 @@ nm_dhcp_manager_begin_transaction (NMDHCPManager *manager,
nm_dhcp_manager_cancel_transaction_real (device);
}
 
-   nm_info ("Activation (%s) Beginning DHCP transaction.", iface);
+   if (timeout == 0)
+   timeout = NM_DHCP_TIMEOUT;
+
+   nm_info ("Activation (%s) Beginning DHCP transaction (timeout in %d 
seconds)",
+iface, timeout);
 
device->pid = nm_dhcp_client_start (device, uuid, s_ip4);
if (device->pid == 0)
return FALSE;
 
-   if (timeout == 0)
-   timeout = NM_DHCP_TIMEOUT;
-
/* Set up a timeout on the transaction to kill it after the timeout */
device->timeout_id = g_timeout_add_seconds (timeout,

nm_dhcp_manager_handle_timeout,
diff --git a/src/nm-device.c b/src/nm-device.c
index 1506b96..c55a9e5 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -91,6 +91,7 @@ struct _NMDevicePrivate
/* IP configuration info */
NMIP4Config *   ip4_config; /* Config from 
DHCP, PPP, or system config files */
NMDHCPManager * dhcp_manager;
+   guint32 dhcp_timeout;
gulong  dhcp_state_sigid;
gulong  dhcp_timeout_sigid;
NMDHCP4Config * dhcp4_config;
@@ -142,6 +143,7 @@ nm_device_init (NMDevice * self)
self->priv->capabilities = NM_DEVICE_CAP_NONE;
memset (&self->priv->ip6_address, 0, sizeof (struct in6_addr));
self->priv->state = NM_DEVICE_STATE_UNMANAGED;
+   self->priv->dhcp_timeout = 0;
 }
 
 static gboolean
@@ -896,7 +898,7 @@ real_act_stage3_ip_config_start (NMDevice *self, 
NMDeviceStateReason *reason)
/* DHCP manager will cancel any transaction already in progress 
and we do not
   want to cancel this activation if we get "down" state from 
that. */
g_signal_handler_block (priv->dhcp_manager, 
priv->dhcp_state_sigid);
-   success = nm_dhcp_manager_begin_transaction 
(priv->dhcp_manager, ip_iface, uuid, s_ip4, 45);
+   success = nm_dhcp_manager_begin_transaction 
(priv->dhcp_manager, ip_iface, uuid, s_ip4, priv->dhcp_timeout);
g_signal_handler_unblock (priv->dhcp_manager, 
priv->dhcp_state_sigid);
 
if (success) {
@@ -2511,3 +2513,12 @@ nm_device_set_managed (NMDevice *device,
nm_device_state_changed (device, NM_DEVICE_STATE_UNMANAGED, 
reason);
 }
 
+void
+nm_device_set_dhcp_timeout (NMDevice *device,
+guint32 timeout)
+{
+   g_return_if_fail (NM_IS_DEVICE (device));
+
+   NM_DEVICE_GET_PRIVATE (device)->dhcp_timeout = timeout;
+}
+
diff --git a/src/nm-device.h b/src/nm-device.h
index f78e1e8..fc394dd 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -165,6 +165,8 @@ void nm_device_set_managed (NMDevice *device,
 gboolean managed,
 NMDeviceStateReason reason);
 
+void nm_device_set_dhcp_timeout (NMDevice *device, guint32 timeout);
+
 G_END_DECLS
 
 #endif /* NM_DEVICE_H */
-- 
1.6.4

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH v0.7 1/6] wifi: add 'scanning' property which is TRUE while device is scanning

[Daniel Drake]

---
 src/nm-device-wifi.c |   34 ++
 src/nm-device-wifi.h |1 +
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
index 2b62b8b..bf03bb7 100644
--- a/src/nm-device-wifi.c
+++ b/src/nm-device-wifi.c
@@ -81,6 +81,7 @@ enum {
PROP_BITRATE,
PROP_ACTIVE_ACCESS_POINT,
PROP_CAPABILITIES,
+   PROP_SCANNING,
 
LAST_PROP
 };
@@ -125,6 +126,7 @@ typedef struct Supplicant {
guint iface_scan_request_result_id;
guint iface_scan_results_id;
guint iface_con_state_id;
+   guint iface_notify_scanning_id;
 
/* Timeouts and idles */
guint iface_con_error_cb_id;
@@ -215,6 +217,10 @@ static void supplicant_mgr_state_cb (NMSupplicantInterface 
* iface,
  guint32 old_state,
  NMDeviceWifi *self);
 
+static void supplicant_iface_notify_scanning_cb (NMSupplicantInterface * iface,
+ GParamSpec * pspec,
+ NMDeviceWifi * self);
+
 static guint32 nm_device_wifi_get_bitrate (NMDeviceWifi *self);
 
 static void cull_scan_list (NMDeviceWifi *self);
@@ -625,6 +631,12 @@ supplicant_interface_acquire (NMDeviceWifi *self)
   self);
priv->supplicant.iface_con_state_id = id;
 
+   id = g_signal_connect (priv->supplicant.iface,
+  "notify::scanning",
+  G_CALLBACK (supplicant_iface_notify_scanning_cb),
+  self);
+   priv->supplicant.iface_notify_scanning_id = id;
+
return TRUE;
 }
 
@@ -716,6 +728,11 @@ supplicant_interface_release (NMDeviceWifi *self)
priv->supplicant.iface_con_state_id = 0;
}
 
+   if (priv->supplicant.iface_notify_scanning_id > 0) {
+   g_signal_handler_disconnect (priv->supplicant.iface, 
priv->supplicant.iface_notify_scanning_id);
+   priv->supplicant.iface_notify_scanning_id = 0;
+   }
+
if (priv->supplicant.iface) {
/* Tell the supplicant to disconnect from the current AP */
nm_supplicant_interface_disconnect (priv->supplicant.iface);
@@ -2447,6 +2464,14 @@ supplicant_iface_connection_error_cb 
(NMSupplicantInterface * iface,
 }
 
 static void
+supplicant_iface_notify_scanning_cb (NMSupplicantInterface * iface,
+ GParamSpec * pspec,
+ NMDeviceWifi * self)
+{
+   g_object_notify (G_OBJECT (self), "scanning");
+}
+
+static void
 remove_supplicant_connection_timeout (NMDeviceWifi *self)
 {
NMDeviceWifiPrivate *priv;
@@ -3237,6 +3262,9 @@ get_property (GObject *object, guint prop_id,
else
g_value_set_boxed (value, "/");
break;
+   case PROP_SCANNING:
+   g_value_set_boolean (value, 
nm_supplicant_interface_get_scanning (priv->supplicant.iface));
+   break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
@@ -3315,6 +3343,12 @@ nm_device_wifi_class_init (NMDeviceWifiClass *klass)
   0, G_MAXUINT32, NM_WIFI_DEVICE_CAP_NONE,
   G_PARAM_READABLE));
 
+   g_object_class_install_property (object_class, PROP_SCANNING,
+   g_param_spec_boolean (NM_DEVICE_WIFI_SCANNING,
+  "Scanning",
+  "Scanning",
+  0, G_PARAM_READABLE));
+
/* Signals */
signals[ACCESS_POINT_ADDED] =
g_signal_new ("access-point-added",
diff --git a/src/nm-device-wifi.h b/src/nm-device-wifi.h
index 1e885cb..c53a50c 100644
--- a/src/nm-device-wifi.h
+++ b/src/nm-device-wifi.h
@@ -47,6 +47,7 @@ G_BEGIN_DECLS
 #define NM_DEVICE_WIFI_BITRATE "bitrate"
 #define NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT "active-access-point"
 #define NM_DEVICE_WIFI_CAPABILITIES "wireless-capabilities"
+#define NM_DEVICE_WIFI_SCANNING "scanning"
 
 #ifndef NM_DEVICE_WIFI_DEFINED
 #define NM_DEVICE_WIFI_DEFINED
-- 
1.6.4

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

OLPC mesh support backported to NM-0.7

[Daniel Drake]

Hi Dan,

I'm sending you 6 patches which backport the NM mesh support to the
v0.7 branch. They are all direct backports from the patches you
committed to master, with only the minimal changes needed to get
things working on 0.7. I've tested it with my modified Sugar and it is
working well.

Daniel
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

1 step closer to XO-1 mesh again

[Daniel Drake]

NetworkManager git master (to be released as v0.8, for Fedora 12) now
includes support for the mesh hardware in the XO-1.

so the next step is just to backport 6 patches to NM-0.7 so that they
can be included in Fedora while we're waiting for F12, and then to fix
up my Sugar patch for sugar-0.86. anyone interested?

all details here:
http://wiki.laptop.org/go/Network_manager_0.7
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] OLPC Mesh interface support

[Daniel Drake]

On Thu, 2009-07-16 at 11:11 -0400, Dan Williams wrote:
> I just published the "inhibit" branch, but I decided to just apply your
> patch anyway and use the dbus-settable inhibit in parallel with your
> signal method.

OK. I think your method isn't perfect for the mesh-inhibits-companion
case, because if the mesh were to set that property on the companion
then that decision could be overridden by some other process sending a
dbus message. Thanks for merging both!

I saw your "merge autoconnect inhibit logic" patch -- another way you
could implement that is to make each NMDevice respond to its own
autoconnect-allowed signal, based on the value of
priv->autoconnect_inhibit.

> However, we do want to probably handle the Manager stuff differently,
> but I"ll work on that.

Thanks!

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH v2] OLPC Mesh interface support

[Daniel Drake]

 FIXME: check changed parameters.
+
+
+
+Emitted when the wireless device's properties changed.
+
+
+  
+
diff --git a/libnm-util/Makefile.am b/libnm-util/Makefile.am
index bc7befb..4004b10 100644
--- a/libnm-util/Makefile.am
+++ b/libnm-util/Makefile.am
@@ -22,6 +22,7 @@ libnm_util_include_HEADERS =  \
nm-setting-serial.h \
nm-setting-gsm.h\
nm-setting-cdma.h   \
+   nm-setting-olpc-mesh.h  \
nm-setting-wired.h  \
nm-setting-wireless.h   \
nm-setting-wireless-security.h  \
@@ -45,6 +46,7 @@ libnm_util_la_SOURCES=\
nm-setting-serial.c \
nm-setting-gsm.c\
nm-setting-cdma.c   \
+   nm-setting-olpc-mesh.c  \
nm-setting-wired.c  \
nm-setting-wireless.c   \
nm-setting-wireless-security.c  \
diff --git a/libnm-util/libnm-util.ver b/libnm-util/libnm-util.ver
index 4d372a7..289192d 100644
--- a/libnm-util/libnm-util.ver
+++ b/libnm-util/libnm-util.ver
@@ -253,6 +253,10 @@ global:
nm_setting_wireless_security_remove_pairwise;
nm_setting_wireless_security_remove_proto;
nm_setting_wireless_security_set_wep_key;
+   nm_setting_olpc_mesh_get_type;
+   nm_setting_olpc_mesh_get_ssid;
+   nm_setting_olpc_mesh_get_channel;
+   nm_setting_olpc_mesh_get_dhcp_anycast_address;
nm_utils_deinit;
nm_utils_escape_ssid;
nm_utils_gvalue_hash_dup;
diff --git a/libnm-util/nm-connection.c b/libnm-util/nm-connection.c
index e016023..15331c8 100644
--- a/libnm-util/nm-connection.c
+++ b/libnm-util/nm-connection.c
@@ -41,6 +41,7 @@
 #include "nm-setting-wireless.h"
 #include "nm-setting-wireless-security.h"
 #include "nm-setting-vpn.h"
+#include "nm-setting-olpc-mesh.h"
 
 #include "nm-setting-serial.h"
 #include "nm-setting-gsm.h"
@@ -216,6 +217,11 @@ register_default_settings (void)
  NM_SETTING_WIRELESS_ERROR,
  1);
 
+   register_one_setting (NM_SETTING_OLPC_MESH_SETTING_NAME,
+ NM_TYPE_SETTING_OLPC_MESH,
+ NM_SETTING_OLPC_MESH_ERROR,
+ 1);
+
register_one_setting (NM_SETTING_GSM_SETTING_NAME,
  NM_TYPE_SETTING_GSM,
  NM_SETTING_GSM_ERROR,
diff --git a/libnm-util/nm-setting-olpc-mesh.c 
b/libnm-util/nm-setting-olpc-mesh.c
new file mode 100644
index 000..2202469
--- /dev/null
+++ b/libnm-util/nm-setting-olpc-mesh.c
@@ -0,0 +1,265 @@
+/* -*- Mode: C; tab-width: 5; indent-tabs-mode: t; c-basic-offset: 5 -*- */
+
+/*
+ * Dan Williams 
+ * Tambet Ingo 
+ * Sjoerd Simons 
+ * Daniel Drake 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301 USA.
+ *
+ * (C) Copyright 2007 - 2008 Red Hat, Inc.
+ * (C) Copyright 2007 - 2008 Novell, Inc.
+ * (C) Copyright 2009 One Laptop per Child
+ */
+
+#include 
+#include 
+#include 
+
+#include "NetworkManager.h"
+#include "nm-setting-olpc-mesh.h"
+#include "nm-param-spec-specialized.h"
+#include "nm-utils.h"
+#include "nm-dbus-glib-types.h"
+#include "nm-utils-private.h"
+
+GQuark
+nm_setting_olpc_mesh_error_quark (void)
+{
+   static GQuark quark;
+
+   if (G_UNLIKELY (!quark))
+   quark = g_quark_from_static_string 
("nm-setting-wireless-mesh-error-quark");
+   return quark;
+}
+
+/* This should really be standard. */
+#define ENUM_ENTRY(NAME, DESC) { NAME, "" #NAME "", DESC }
+
+GType
+nm_setting_olpc_mesh_error_get_type (void)
+{
+   static GType etype = 0;
+
+   if (etype == 0) {
+   static const GEnumValue values[] = {
+   /* Unknown error. */
+   ENUM_ENTRY (NM_SETTING_OLPC_MESH_ERROR_UNKNOWN, 
"UnknownError"),
+   /* The specified property was invalid. */
+   ENUM_ENTRY 
(NM_SETTING_OLPC_MESH_ERROR_INVALID_PROPERTY, "InvalidPr

Re: [PATCH] OLPC Mesh interface support

[Daniel Drake]

On Wed, 2009-07-15 at 14:15 -0400, Dan Williams wrote:
> A few things...  can you post the udev rules file so we can add that
> too?  I'd like to change that from NM_DEVICE_TYPE to ID_NM_OLPC_MESH to
> be more in keeping with udev's property naming.

Ok, then the rule will be

KERNEL=="msh*", SUBSYSTEM=="net", DRIVERS=="usb", ATTRS{idVendor}=="1286", 
ATTRS{idProduct}=="2001", ENV{ID_NM_OLPC_MESH}="1"

For some reason, the fact that it's driven by libertas doesn't get
exposed in the sysfs tree.

> Second, the autoconnect inhibit stuff is pretty elegant the way you've
> implemented it, but I'd like to see if we could implement it with the
> inhibit stuff I've got going on in another branch (which is a property
> on the device instead of a signal).  If you can't do that then maybe I
> can.

OK, where can I find this branch?

> Third, we try not to let the devices themselves have direct access to
> the manager for a few reasons (Tambet was the one who originally
> architected it that way) so I'd like to either revisit that restriction
> or have the manager pass the device list into the device creators and
> then call device-added/removed functions.  That basically duplicates
> signals (bad) but doesn't require the manager object (good).
> 
> I'll try to poke Tambet on #3.  OLPC is obviously the first device we've
> had that is so tightly tied to another.
> 
> So this means I've applied 1, 2, 3 and 5, but not the
> autoconnect-inhibit and not the main OLPC mesh patch yet.

Great, thanks!

I'll be able to work on the udev rule tweaking and the autoconnect stuff
tomorrow (if you can point me to it).

After that, I'm off to do volunteer work on the project in Nepal but
hopefully will be able to itch away at this in the evenings.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] OLPC Mesh interface support

[Daniel Drake]

ESH_SETTING_NAME,
+ NM_TYPE_SETTING_OLPC_MESH,
+ NM_SETTING_OLPC_MESH_ERROR,
+ 1);
+
register_one_setting (NM_SETTING_GSM_SETTING_NAME,
  NM_TYPE_SETTING_GSM,
  NM_SETTING_GSM_ERROR,
diff --git a/libnm-util/nm-setting-olpc-mesh.c 
b/libnm-util/nm-setting-olpc-mesh.c
new file mode 100644
index 000..2202469
--- /dev/null
+++ b/libnm-util/nm-setting-olpc-mesh.c
@@ -0,0 +1,265 @@
+/* -*- Mode: C; tab-width: 5; indent-tabs-mode: t; c-basic-offset: 5 -*- */
+
+/*
+ * Dan Williams 
+ * Tambet Ingo 
+ * Sjoerd Simons 
+ * Daniel Drake 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301 USA.
+ *
+ * (C) Copyright 2007 - 2008 Red Hat, Inc.
+ * (C) Copyright 2007 - 2008 Novell, Inc.
+ * (C) Copyright 2009 One Laptop per Child
+ */
+
+#include 
+#include 
+#include 
+
+#include "NetworkManager.h"
+#include "nm-setting-olpc-mesh.h"
+#include "nm-param-spec-specialized.h"
+#include "nm-utils.h"
+#include "nm-dbus-glib-types.h"
+#include "nm-utils-private.h"
+
+GQuark
+nm_setting_olpc_mesh_error_quark (void)
+{
+   static GQuark quark;
+
+   if (G_UNLIKELY (!quark))
+   quark = g_quark_from_static_string 
("nm-setting-wireless-mesh-error-quark");
+   return quark;
+}
+
+/* This should really be standard. */
+#define ENUM_ENTRY(NAME, DESC) { NAME, "" #NAME "", DESC }
+
+GType
+nm_setting_olpc_mesh_error_get_type (void)
+{
+   static GType etype = 0;
+
+   if (etype == 0) {
+   static const GEnumValue values[] = {
+   /* Unknown error. */
+   ENUM_ENTRY (NM_SETTING_OLPC_MESH_ERROR_UNKNOWN, 
"UnknownError"),
+   /* The specified property was invalid. */
+   ENUM_ENTRY 
(NM_SETTING_OLPC_MESH_ERROR_INVALID_PROPERTY, "InvalidProperty"),
+   /* The specified property was missing and is required. 
*/
+   ENUM_ENTRY 
(NM_SETTING_OLPC_MESH_ERROR_MISSING_PROPERTY, "MissingProperty"),
+   { 0, 0, 0 }
+   };
+   etype = g_enum_register_static ("NMSettingWirelessError", 
values);
+   }
+   return etype;
+}
+
+static void nm_setting_olpc_mesh_init (NMSettingOlpcMesh *setting);
+
+G_DEFINE_TYPE (NMSettingOlpcMesh, nm_setting_olpc_mesh, NM_TYPE_SETTING)
+
+#define NM_SETTING_OLPC_MESH_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE ((o), 
NM_TYPE_SETTING_OLPC_MESH, NMSettingOlpcMeshPrivate))
+
+typedef struct {
+   GByteArray *ssid;
+   guint32 channel;
+   GByteArray *dhcp_anycast_addr;
+} NMSettingOlpcMeshPrivate;
+
+enum {
+   PROP_0,
+   PROP_SSID,
+   PROP_CHANNEL,
+   PROP_DHCP_ANYCAST_ADDRESS,
+
+   LAST_PROP
+};
+
+static void
+nm_setting_olpc_mesh_init (NMSettingOlpcMesh *setting)
+{
+   g_object_set (setting, NM_SETTING_NAME, 
NM_SETTING_OLPC_MESH_SETTING_NAME, NULL);
+}
+
+const GByteArray *
+nm_setting_olpc_mesh_get_ssid (NMSettingOlpcMesh *setting)
+{
+   g_return_val_if_fail (NM_IS_SETTING_OLPC_MESH (setting), NULL);
+
+   return NM_SETTING_OLPC_MESH_GET_PRIVATE (setting)->ssid;
+}
+
+guint32
+nm_setting_olpc_mesh_get_channel (NMSettingOlpcMesh *setting)
+{
+   g_return_val_if_fail (NM_IS_SETTING_OLPC_MESH (setting), 0);
+
+   return NM_SETTING_OLPC_MESH_GET_PRIVATE (setting)->channel;
+}
+
+const GByteArray *
+nm_setting_olpc_mesh_get_dhcp_anycast_address (NMSettingOlpcMesh *setting)
+{
+   g_return_val_if_fail (NM_IS_SETTING_OLPC_MESH (setting), NULL);
+
+   return NM_SETTING_OLPC_MESH_GET_PRIVATE (setting)->dhcp_anycast_addr;
+}
+
+static gboolean
+verify (NMSetting *setting, GSList *all_settings, GError **error)
+{
+   NMSettingOlpcMeshPrivate *priv = NM_SETTING_OLPC_MESH_GET_PRIVATE 
(setting);
+
+   if (!priv->ssid) {
+   g_set_error (error,
+NM_SETTING_OLPC_MESH_ERROR,
+NM_SETTING_OLPC_MESH_ERROR_MISSING_PROPERTY,
+NM

Re: [PATCH] Allow devices to inhibit scanning through a signal

[Daniel Drake]

On Wed, 2009-07-08 at 15:40 +0200, Alexander Sack wrote:
> Just curious, where and how are you planning to implement the
> SCANNING_ALLOWED signal handler? Is there a patch coming for that
> too?

You don't have to implement it -- if there are no handlers then the
behaviour is unchanged (scans are allowed subject to the other
conditions).

The OLPC mesh device does add a signal handler though, on it's companion
wlan device. We want to prevent scans from taking place while we're
looking around for mesh portals.

static gboolean
companion_scan_allowed_cb (NMDeviceWifi *companion, gpointer user_data)
{
NMDeviceOlpcMesh *self = NM_DEVICE_OLPC_MESH (user_data);
NMDeviceState state;

g_object_get (G_OBJECT (self), NM_DEVICE_INTERFACE_STATE, &state, NULL);

/* Don't allow the companion to scan while configure the mesh interface 
*/
return state < NM_DEVICE_STATE_PREPARE
|| state > NM_DEVICE_STATE_IP_CONFIG;
}

I'm sending the patch for the full mesh device implementation right now.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] Allow devices to inhibit autoconnect through a signal

[Daniel Drake]

This allows a device (or a companion) to signal that it is not a good
time for a specific device to autoconnect to a network.

The OLPC mesh device will use this to prevent automatic connection
to WLAN networks while the mesh device is active.
---
 src/NetworkManagerPolicy.c |2 +-
 src/nm-device.c|   45 
 src/nm-device.h|1 +
 3 files changed, 47 insertions(+), 1 deletions(-)

For master branch

diff --git a/src/NetworkManagerPolicy.c b/src/NetworkManagerPolicy.c
index b1b485c..2cb39cb 100644
--- a/src/NetworkManagerPolicy.c
+++ b/src/NetworkManagerPolicy.c
@@ -723,7 +723,7 @@ schedule_activate_check (NMPolicy *policy, NMDevice *device)
if (state < NM_DEVICE_STATE_DISCONNECTED)
return;
 
-   if (!nm_device_can_activate (device))
+   if (!nm_device_can_activate (device) || !nm_device_autoconnect_allowed 
(device))
return;
 
for (iter = policy->pending_activation_checks; iter; iter = 
g_slist_next (iter)) {
diff --git a/src/nm-device.c b/src/nm-device.c
index 06cfaf1..4957739 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -50,6 +50,7 @@
 #include "nm-setting-connection.h"
 #include "nm-dnsmasq-manager.h"
 #include "nm-dhcp4-config.h"
+#include "nm-marshal.h"
 
 #define NM_ACT_REQUEST_IP4_CONFIG "nm-act-request-ip4-config"
 
@@ -58,6 +59,13 @@ static void device_interface_init (NMDeviceInterface 
*device_interface_class);
 G_DEFINE_TYPE_EXTENDED (NMDevice, nm_device, G_TYPE_OBJECT, 
G_TYPE_FLAG_ABSTRACT,
G_IMPLEMENT_INTERFACE 
(NM_TYPE_DEVICE_INTERFACE, device_interface_init))
 
+enum {
+   AUTOCONNECT_ALLOWED,
+   LAST_SIGNAL,
+};
+
+static guint signals[LAST_SIGNAL] = { 0 };
+
 #define NM_DEVICE_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE ((o), 
NM_TYPE_DEVICE, NMDevicePrivate))
 
 typedef struct {
@@ -366,6 +374,34 @@ nm_device_can_activate (NMDevice *self)
return TRUE;
 }
 
+static gboolean
+autoconnect_allowed_accumulator (GSignalInvocationHint *ihint,
+ GValue *return_accu,
+ const GValue *handler_return, gpointer data)
+{
+   if (!g_value_get_boolean (handler_return))
+   g_value_set_boolean (return_accu, FALSE);
+   return TRUE;
+}
+
+gboolean
+nm_device_autoconnect_allowed (NMDevice *self)
+{
+   GValue instance = { 0, };
+   GValue retval = { 0, };
+
+   g_value_init (&instance, G_TYPE_OBJECT);
+   g_value_take_object (&instance, self);
+
+   g_value_init (&retval, G_TYPE_BOOLEAN);
+   g_value_set_boolean (&retval, TRUE);
+
+   /* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
+* value being changed if no handlers are connected */
+   g_signal_emitv (&instance, signals[AUTOCONNECT_ALLOWED], 0, &retval);
+   return g_value_get_boolean (&retval);
+}
+
 NMConnection *
 nm_device_get_best_auto_connection (NMDevice *dev,
 GSList *connections,
@@ -2399,6 +2435,15 @@ nm_device_class_init (NMDeviceClass *klass)
g_object_class_override_property (object_class,
  
NM_DEVICE_INTERFACE_PROP_TYPE_DESC,
  
NM_DEVICE_INTERFACE_TYPE_DESC);
+
+   signals[AUTOCONNECT_ALLOWED] =
+   g_signal_new ("autoconnect-allowed",
+ G_OBJECT_CLASS_TYPE (object_class),
+ G_SIGNAL_RUN_LAST,
+ 0,
+ autoconnect_allowed_accumulator, NULL,
+ _nm_marshal_BOOLEAN__VOID,
+ G_TYPE_BOOLEAN, 0);
 }
 
 static gboolean
diff --git a/src/nm-device.h b/src/nm-device.h
index 45a3f9e..31c58fb 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -154,6 +154,7 @@ void
nm_device_activate_schedule_stage4_ip_config_timeout(NMDevice *device);
 gboolean   nm_device_deactivate_quickly(NMDevice *dev);
 gboolean   nm_device_is_activating (NMDevice *dev);
 gboolean   nm_device_can_interrupt_activation  
(NMDevice *self);
+gboolean   nm_device_autoconnect_allowed   (NMDevice *self);
 
 NMDeviceState nm_device_get_state (NMDevice *device);
 
-- 
1.6.2.5

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] Internally configurable DHCP anycast address

[Daniel Drake]

A DHCP anycast address can now be specified for each NMDevice.
The OLPC mesh device will use this to target DHCP requests at
the predefined mesh portal anycast addresses.
---
 src/dhcp-manager/nm-dhcp-dhclient.c |   22 ++
 src/dhcp-manager/nm-dhcp-dhcpcd.c   |3 ++-
 src/dhcp-manager/nm-dhcp-manager.c  |5 +++--
 src/dhcp-manager/nm-dhcp-manager.h  |6 --
 src/nm-device.c |   31 ++-
 src/nm-device.h |1 +
 6 files changed, 58 insertions(+), 10 deletions(-)

For master branch

diff --git a/src/dhcp-manager/nm-dhcp-dhclient.c 
b/src/dhcp-manager/nm-dhcp-dhclient.c
index 28b5a23..d5b723b 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient.c
@@ -84,6 +84,7 @@ get_leasefile_for_iface (const char * iface, const char *uuid)
 static gboolean
 merge_dhclient_config (NMDHCPDevice *device,
NMSettingIP4Config *s_ip4,
+   guint8 *anycast_addr,
const char *contents,
const char *orig,
GError **error)
@@ -143,6 +144,16 @@ merge_dhclient_config (NMDHCPDevice *device,
g_string_append_printf (new_contents, 
DHCP_HOSTNAME_FORMAT "\n", tmp);
}
 
+   if (anycast_addr)
+   g_string_append_printf (new_contents, "interface \"%s\" {\n"
+   " initial-interval 1; \n"
+   " anycast-mac ethernet 
%02x:%02x:%02x:%02x:%02x:%02x;\n"
+   "}\n",
+   device->iface,
+anycast_addr[0], anycast_addr[1],
+anycast_addr[2], anycast_addr[3],
+anycast_addr[4], anycast_addr[5]);
+
if (g_file_set_contents (device->conf_file, new_contents->str, -1, 
error))
success = TRUE;
 
@@ -157,7 +168,9 @@ merge_dhclient_config (NMDHCPDevice *device,
  * config file along with the NM options.
  */
 static gboolean
-create_dhclient_config (NMDHCPDevice *device, NMSettingIP4Config *s_ip4)
+create_dhclient_config (NMDHCPDevice *device,
+NMSettingIP4Config *s_ip4,
+guint8 *dhcp_anycast_addr)
 {
char *orig = NULL, *contents = NULL;
GError *error = NULL;
@@ -197,7 +210,7 @@ create_dhclient_config (NMDHCPDevice *device, 
NMSettingIP4Config *s_ip4)
 
 out:
error = NULL;
-   if (merge_dhclient_config (device, s_ip4, contents, orig, &error))
+   if (merge_dhclient_config (device, s_ip4, dhcp_anycast_addr, contents, 
orig, &error))
success = TRUE;
else {
nm_warning ("%s: error creating dhclient configuration: %s",
@@ -223,7 +236,8 @@ dhclient_child_setup (gpointer user_data G_GNUC_UNUSED)
 GPid
 nm_dhcp_client_start (NMDHCPDevice *device,
   const char *uuid,
-  NMSettingIP4Config *s_ip4)
+  NMSettingIP4Config *s_ip4,
+  guint8 *dhcp_anycast_addr)
 {
GPtrArray *dhclient_argv = NULL;
GPid pid = 0;
@@ -247,7 +261,7 @@ nm_dhcp_client_start (NMDHCPDevice *device,
goto out;
}
 
-   if (!create_dhclient_config (device, s_ip4))
+   if (!create_dhclient_config (device, s_ip4, dhcp_anycast_addr))
goto out;
 
/* Kill any existing dhclient bound to this interface */
diff --git a/src/dhcp-manager/nm-dhcp-dhcpcd.c 
b/src/dhcp-manager/nm-dhcp-dhcpcd.c
index 05db9dd..a6ce8d2 100644
--- a/src/dhcp-manager/nm-dhcp-dhcpcd.c
+++ b/src/dhcp-manager/nm-dhcp-dhcpcd.c
@@ -62,7 +62,8 @@ dhcpcd_child_setup (gpointer user_data G_GNUC_UNUSED)
 GPid
 nm_dhcp_client_start (NMDHCPDevice *device,
   const char *uuid,
-  NMSettingIP4Config *s_ip4)
+  NMSettingIP4Config *s_ip4,
+  guint8 *dhcp_anycast_addr)
 {
GPtrArray *argv = NULL;
GPid pid = 0;
diff --git a/src/dhcp-manager/nm-dhcp-manager.c 
b/src/dhcp-manager/nm-dhcp-manager.c
index c068f10..9c3be37 100644
--- a/src/dhcp-manager/nm-dhcp-manager.c
+++ b/src/dhcp-manager/nm-dhcp-manager.c
@@ -588,7 +588,8 @@ nm_dhcp_manager_begin_transaction (NMDHCPManager *manager,
const char *iface,
const char *uuid,
NMSettingIP4Config *s_ip4,
-   guint32 timeout)
+   guint32 timeout,
+   guint8 *dhcp_anycast_addr)
 {
NMDHCPManagerPrivate *priv;
NMDHCPDevice *device;
@@ -629,7 +630,7 @@ nm_dhcp_manager_begin_transaction (NMDHCPManager *manager,
timeout = NM_DHCP_TIMEOUT;
 
nm_info ("Activation (%s) Beginning DHC

[PATCH] Make DHCP timeout overridable

[Daniel Drake]

The OLPC mesh device will want a lower timeout as it probes the various
channels for different connectivity portals.
---
 src/dhcp-manager/nm-dhcp-manager.c |   12 ++--
 src/nm-device.c|   13 -
 src/nm-device.h|2 ++
 3 files changed, 20 insertions(+), 7 deletions(-)

For master branch

diff --git a/src/dhcp-manager/nm-dhcp-manager.c 
b/src/dhcp-manager/nm-dhcp-manager.c
index 66044d7..c068f10 100644
--- a/src/dhcp-manager/nm-dhcp-manager.c
+++ b/src/dhcp-manager/nm-dhcp-manager.c
@@ -508,8 +508,8 @@ nm_dhcp_manager_handle_timeout (gpointer user_data)
 {
NMDHCPDevice *device = (NMDHCPDevice *) user_data;
 
-   nm_info ("(%s): DHCP transaction took too long (>%ds), stopping it.",
-device->iface, NM_DHCP_TIMEOUT);
+   nm_info ("(%s): DHCP transaction took too long, stopping it.",
+device->iface);
 
nm_dhcp_manager_cancel_transaction (device->manager, device->iface);
 
@@ -625,7 +625,10 @@ nm_dhcp_manager_begin_transaction (NMDHCPManager *manager,
setting = s_ip4 ? g_object_ref (s_ip4) : NULL;
}
 
-   nm_info ("Activation (%s) Beginning DHCP transaction.", iface);
+   if (timeout == 0)
+   timeout = NM_DHCP_TIMEOUT;
+
+   nm_info ("Activation (%s) Beginning DHCP transaction (timeout in 
%dsecs)", iface, timeout);
device->pid = nm_dhcp_client_start (device, uuid, setting);
 
if (setting)
@@ -634,9 +637,6 @@ nm_dhcp_manager_begin_transaction (NMDHCPManager *manager,
if (device->pid == 0)
return FALSE;
 
-   if (timeout == 0)
-   timeout = NM_DHCP_TIMEOUT;
-
/* Set up a timeout on the transaction to kill it after the timeout */
device->timeout_id = g_timeout_add_seconds (timeout,

nm_dhcp_manager_handle_timeout,
diff --git a/src/nm-device.c b/src/nm-device.c
index 55a8fed..114712c 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -89,6 +89,7 @@ typedef struct {
/* IP configuration info */
NMIP4Config *   ip4_config; /* Config from DHCP, 
PPP, or system config files */
NMDHCPManager * dhcp_manager;
+   guint32 dhcp_timeout;
gulong  dhcp_state_sigid;
gulong  dhcp_timeout_sigid;
NMDHCP4Config * dhcp4_config;
@@ -142,6 +143,7 @@ nm_device_init (NMDevice *self)
priv->capabilities = NM_DEVICE_CAP_NONE;
memset (&priv->ip6_address, 0, sizeof (struct in6_addr));
priv->state = NM_DEVICE_STATE_UNMANAGED;
+   priv->dhcp_timeout = 0;
 }
 
 static GObject*
@@ -899,7 +901,7 @@ real_act_stage3_ip_config_start (NMDevice *self, 
NMDeviceStateReason *reason)
/* DHCP manager will cancel any transaction already in progress 
and we do not
   want to cancel this activation if we get "down" state from 
that. */
g_signal_handler_block (priv->dhcp_manager, 
priv->dhcp_state_sigid);
-   success = nm_dhcp_manager_begin_transaction 
(priv->dhcp_manager, ip_iface, uuid, s_ip4, 45);
+   success = nm_dhcp_manager_begin_transaction 
(priv->dhcp_manager, ip_iface, uuid, s_ip4, priv->dhcp_timeout);
g_signal_handler_unblock (priv->dhcp_manager, 
priv->dhcp_state_sigid);
 
if (success) {
@@ -2536,3 +2538,12 @@ nm_device_spec_match_list (NMDeviceInterface *device, 
const GSList *specs)
return FALSE;
 }
 
+void
+nm_device_set_dhcp_timeout (NMDevice *device,
+guint32 timeout)
+{
+   g_return_if_fail (NM_IS_DEVICE (device));
+
+   NM_DEVICE_GET_PRIVATE (device)->dhcp_timeout = timeout;
+}
+
diff --git a/src/nm-device.h b/src/nm-device.h
index d460352..3900393 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -162,6 +162,8 @@ void nm_device_set_managed (NMDevice *device,
 gboolean managed,
 NMDeviceStateReason reason);
 
+void nm_device_set_dhcp_timeout (NMDevice *device, guint32 timeout);
+
 G_END_DECLS
 
 #endif /* NM_DEVICE_H */
-- 
1.6.2.5

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] Improve wifi scanning throttling code

[Daniel Drake]

From: Sjoerd Simons 

Throttle requesting scan results to be at least four seconds, instead
of always forcing a 4 second delay after the first scan.
---
 src/supplicant-manager/nm-supplicant-interface.c |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

For master branch

diff --git a/src/supplicant-manager/nm-supplicant-interface.c 
b/src/supplicant-manager/nm-supplicant-interface.c
index 636005e..00f0c30 100644
--- a/src/supplicant-manager/nm-supplicant-interface.c
+++ b/src/supplicant-manager/nm-supplicant-interface.c
@@ -597,15 +597,23 @@ static void
 wpas_iface_query_scan_results (DBusGProxy *proxy, gpointer user_data)
 {
NMSupplicantInterfacePrivate *priv = 
NM_SUPPLICANT_INTERFACE_GET_PRIVATE (user_data);
+   GTimeVal cur_time;
 
/* Only query scan results if a query is not queued */
if (priv->scan_results_timeout)
return;
 
+   g_get_current_time (&cur_time);
+
/* Only fetch scan results every 4s max, but initially do it right away 
*/
-   priv->scan_results_timeout = g_timeout_add_seconds (priv->last_scan ? 4 
: 0,
-   
request_scan_results,
-   user_data);
+   if (priv->last_scan + 4 < cur_time.tv_sec) {
+   priv->scan_results_timeout = g_idle_add (request_scan_results,
+user_data);
+   } else {
+   priv->scan_results_timeout =
+   g_timeout_add_seconds ((4 - (cur_time.tv_sec - 
priv->last_scan)),
+  request_scan_results, user_data);
+   }
 }
 
 static guint32
-- 
1.6.2.5

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] Allow devices to inhibit scanning through a signal

[Daniel Drake]

The OLPC mesh device will use this mechanism to prevent scans taking place
on the companion WLAN device while mesh discovery/connectivity is underway.

Based on earlier work by Sjoerd Simons
---
 marshallers/nm-marshal.list |1 +
 src/nm-device-wifi.c|   50 ++-
 2 files changed, 50 insertions(+), 1 deletions(-)

For master branch

diff --git a/marshallers/nm-marshal.list b/marshallers/nm-marshal.list
index 970fe24..6b855f9 100644
--- a/marshallers/nm-marshal.list
+++ b/marshallers/nm-marshal.list
@@ -21,4 +21,5 @@ VOID:POINTER,STRING
 POINTER:POINTER
 VOID:STRING,BOXED
 BOOLEAN:POINTER,STRING,BOOLEAN,UINT,STRING,STRING
+BOOLEAN:VOID
 
diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
index 3538825..cc8b307 100644
--- a/src/nm-device-wifi.c
+++ b/src/nm-device-wifi.c
@@ -37,6 +37,7 @@
 #include "nm-device-interface.h"
 #include "nm-device-private.h"
 #include "nm-utils.h"
+#include "nm-marshal.h"
 #include "NetworkManagerUtils.h"
 #include "NetworkManagerPolicy.h"
 #include "nm-activation-request.h"
@@ -92,6 +93,7 @@ enum {
ACCESS_POINT_REMOVED,
HIDDEN_AP_FOUND,
PROPERTIES_CHANGED,
+   SCANNING_ALLOWED,
 
LAST_SIGNAL
 };
@@ -227,6 +229,11 @@ static guint32 nm_device_wifi_get_bitrate (NMDeviceWifi 
*self);
 
 static void cull_scan_list (NMDeviceWifi *self);
 
+static gboolean scan_allowed_accumulator (GSignalInvocationHint *ihint,
+  GValue *return_accu,
+  const GValue *handler_return,
+  gpointer data);
+
 static GQuark
 nm_wifi_error_quark (void)
 {
@@ -1670,13 +1677,45 @@ can_scan (NMDeviceWifi *self)
 }
 
 static gboolean
+scan_allowed_accumulator (GSignalInvocationHint *ihint,
+  GValue *return_accu,
+  const GValue *handler_return,
+  gpointer data)
+{
+   if (!g_value_get_boolean (handler_return))
+   g_value_set_boolean (return_accu, FALSE);
+   return TRUE;
+}
+
+static gboolean
+scan_allowed (NMDeviceWifi *self)
+{
+   GValue instance = { 0, };
+   GValue retval = { 0, };
+
+   g_value_init (&instance, G_TYPE_OBJECT);
+   g_value_take_object (&instance, self);
+
+   g_value_init (&retval, G_TYPE_BOOLEAN);
+   g_value_set_boolean (&retval, TRUE);
+
+   /* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
+* value being changed if no handlers are connected */
+   g_signal_emitv (&instance, signals[SCANNING_ALLOWED], 0, &retval);
+   if (!g_value_get_boolean (&retval))
+   return FALSE;
+
+   return TRUE;
+}
+
+static gboolean
 request_wireless_scan (gpointer user_data)
 {
NMDeviceWifi *self = NM_DEVICE_WIFI (user_data);
NMDeviceWifiPrivate *priv = NM_DEVICE_WIFI_GET_PRIVATE (self);
gboolean backoff = FALSE;
 
-   if (can_scan (self)) {
+   if (can_scan (self) && scan_allowed (self)) {
if (nm_supplicant_interface_request_scan 
(priv->supplicant.iface)) {
/* success */
backoff = TRUE;
@@ -3615,6 +3654,15 @@ nm_device_wifi_class_init (NMDeviceWifiClass *klass)
nm_properties_changed_signal_new (object_class,
  G_STRUCT_OFFSET 
(NMDeviceWifiClass, properties_changed));
 
+   signals[SCANNING_ALLOWED] =
+   g_signal_new ("scanning-allowed",
+ G_OBJECT_CLASS_TYPE (object_class),
+ G_SIGNAL_RUN_LAST,
+ 0,
+ scan_allowed_accumulator, NULL,
+ _nm_marshal_BOOLEAN__VOID,
+ G_TYPE_BOOLEAN, 0);
+
dbus_g_object_type_install_info (G_TYPE_FROM_CLASS (klass), 
&dbus_glib_nm_device_wifi_object_info);
 
dbus_g_error_domain_register (NM_WIFI_ERROR, NULL, NM_TYPE_WIFI_ERROR);
-- 
1.6.2.5

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] NMDeviceWifi: add scanning property

[Daniel Drake]

This allows NMDeviceWifi users to determine if the interface is currently
performing a scan.
---
 src/nm-device-wifi.c |   34 ++
 src/nm-device-wifi.h |1 +
 2 files changed, 35 insertions(+), 0 deletions(-)

For master branch

diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
index f2ada10..3538825 100644
--- a/src/nm-device-wifi.c
+++ b/src/nm-device-wifi.c
@@ -82,6 +82,7 @@ enum {
PROP_ACTIVE_ACCESS_POINT,
PROP_CAPABILITIES,
PROP_IFINDEX,
+   PROP_SCANNING,
 
LAST_PROP
 };
@@ -126,6 +127,7 @@ typedef struct Supplicant {
guint iface_scan_request_result_id;
guint iface_scan_results_id;
guint iface_con_state_id;
+   guint iface_notify_scanning_id;
 
/* Timeouts and idles */
guint iface_con_error_cb_id;
@@ -217,6 +219,10 @@ static void supplicant_mgr_state_cb (NMSupplicantInterface 
* iface,
  guint32 old_state,
  NMDeviceWifi *self);
 
+static void supplicant_iface_notify_scanning_cb (NMSupplicantInterface * iface,
+ GParamSpec * pspec,
+ NMDeviceWifi * self);
+
 static guint32 nm_device_wifi_get_bitrate (NMDeviceWifi *self);
 
 static void cull_scan_list (NMDeviceWifi *self);
@@ -613,6 +619,12 @@ supplicant_interface_acquire (NMDeviceWifi *self)
   self);
priv->supplicant.iface_con_state_id = id;
 
+   id = g_signal_connect (priv->supplicant.iface,
+  "notify::scanning",
+  G_CALLBACK (supplicant_iface_notify_scanning_cb),
+  self);
+   priv->supplicant.iface_notify_scanning_id = id;
+
return TRUE;
 }
 
@@ -704,6 +716,11 @@ supplicant_interface_release (NMDeviceWifi *self)
priv->supplicant.iface_con_state_id = 0;
}
 
+   if (priv->supplicant.iface_notify_scanning_id > 0) {
+   g_signal_handler_disconnect (priv->supplicant.iface, 
priv->supplicant.iface_notify_scanning_id);
+   priv->supplicant.iface_notify_scanning_id = 0;
+   }
+
if (priv->supplicant.iface) {
/* Tell the supplicant to disconnect from the current AP */
nm_supplicant_interface_disconnect (priv->supplicant.iface);
@@ -2439,6 +2456,14 @@ supplicant_iface_connection_error_cb 
(NMSupplicantInterface * iface,
 }
 
 static void
+supplicant_iface_notify_scanning_cb (NMSupplicantInterface * iface,
+ GParamSpec * pspec,
+ NMDeviceWifi * self)
+{
+   g_object_notify (G_OBJECT (self), "scanning");
+}
+
+static void
 remove_supplicant_connection_timeout (NMDeviceWifi *self)
 {
NMDeviceWifiPrivate *priv;
@@ -3441,6 +3466,9 @@ get_property (GObject *object, guint prop_id,
case PROP_IFINDEX:
g_value_set_uint (value, nm_device_wifi_get_ifindex (device));
break;
+   case PROP_SCANNING:
+   g_value_set_boolean (value, 
nm_supplicant_interface_get_scanning (priv->supplicant.iface));
+   break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
@@ -3546,6 +3574,12 @@ nm_device_wifi_class_init (NMDeviceWifiClass *klass)
   0, G_MAXUINT32, 0,
   G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY));
 
+   g_object_class_install_property (object_class, PROP_SCANNING,
+   g_param_spec_boolean (NM_DEVICE_WIFI_SCANNING,
+  "Scanning",
+  "Scanning",
+  0, G_PARAM_READABLE));
+
/* Signals */
signals[ACCESS_POINT_ADDED] =
g_signal_new ("access-point-added",
diff --git a/src/nm-device-wifi.h b/src/nm-device-wifi.h
index 1b296fb..c86a275 100644
--- a/src/nm-device-wifi.h
+++ b/src/nm-device-wifi.h
@@ -48,6 +48,7 @@ G_BEGIN_DECLS
 #define NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT "active-access-point"
 #define NM_DEVICE_WIFI_CAPABILITIES"wireless-capabilities"
 #define NM_DEVICE_WIFI_IFINDEX "ifindex"
+#define NM_DEVICE_WIFI_SCANNING"scanning"
 
 #ifndef NM_DEVICE_WIFI_DEFINED
 #define NM_DEVICE_WIFI_DEFINED
-- 
1.6.2.5

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

incoming OLPC mesh patches

[Daniel Drake]

Hi Dan,

Thanks a lot for all your help so far! I now have OLPC mesh up and
running on both NetworkManager-0.7 and master, and also have written the
supporting sugar code. It is working nicely, except for that corner-case
related to wpa_supplicant con_state tracking (we can come back to that
later, as it is an isolated problem).

Over the next few hours I'm going to brush up and send you the
NetworkManager patches for the master branch.

Are you also happy to include this work in the 0.7 branch? If so, I will
send the patches for the 0.7 branch after we have got everything
reviewed and committed to master.

Thanks
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] Set device type during construction

[Daniel Drake]

With the recent removal of nm_device_set_device_type(), the DeviceType
property is never set.
---
 src/nm-device-interface.c |2 +-
 src/nm-device.c   |4 
 2 files changed, 5 insertions(+), 1 deletions(-)

For master only

diff --git a/src/nm-device-interface.c b/src/nm-device-interface.c
index 8464683..5647adb 100644
--- a/src/nm-device-interface.c
+++ b/src/nm-device-interface.c
@@ -137,7 +137,7 @@ nm_device_interface_init (gpointer g_iface)
"DeviceType",
"DeviceType",
0, G_MAXUINT32, 
NM_DEVICE_TYPE_UNKNOWN,
-   G_PARAM_READABLE));
+   G_PARAM_READWRITE | 
G_PARAM_CONSTRUCT_ONLY));
 
g_object_interface_install_property
(g_iface, g_param_spec_boolean (NM_DEVICE_INTERFACE_MANAGED,
diff --git a/src/nm-device.c b/src/nm-device.c
index b34795e..55a8fed 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -2232,6 +2232,10 @@ set_property (GObject *object, guint prop_id,
/* construct-only */
priv->udi = g_strdup (g_value_get_string (value));
break;
+   case NM_DEVICE_INTERFACE_PROP_DEVICE_TYPE:
+   /* construct-only */
+   priv->type = g_value_get_uint (value);
+   break;
case NM_DEVICE_INTERFACE_PROP_IFACE:
g_free (priv->iface);
priv->iface = g_value_dup_string (value);
-- 
1.6.2.5

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Sugar + OLPC mesh network selection logic

[Daniel Drake]

On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> > http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi
> 
> Though you're really not going to want to use HAL fdi files for this,
> since master now uses only udev.  You'll either want to hardcode the
> Marvell device IDs into nm-hal-manager (or match on "mshX") or you'll
> want to tag it with udev rules and grab the property from NM instead.

OK. I think udev rules is nicer. Do you think such rules should be
shipped within NM, or in udev itself?

The rule is currently:
KERNEL=="msh*", SUBSYSTEM=="net", DRIVERS=="usb", ATTRS{idVendor}=="1286", 
ATTRS{idProduct}=="2001", ENV{NM_DEVICE_TYPE}="olpcmesh"

I don't know why we can't match on DRIVER=="libertas" (it's blank, must
be a libertas bug) so it's a bit messy. Also soon we will be adding
another rule since the XO-1.5 will come with wifi on SDIO.

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] Add nm-device-bt.xml to distribution

[Daniel Drake]

Fixes a build failure when building from a tarball
---
 introspection/Makefile.am |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

For master branch only

diff --git a/introspection/Makefile.am b/introspection/Makefile.am
index a77dba1..cbd1578 100644
--- a/introspection/Makefile.am
+++ b/introspection/Makefile.am
@@ -6,6 +6,7 @@ EXTRA_DIST = \
nm-access-point.xml \
nm-device-wifi.xml \
nm-device-ethernet.xml \
+   nm-device-bt.xml \
nm-device-cdma.xml \
nm-device-gsm.xml \
nm-device-serial.xml \
-- 
1.6.2.5

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: supplicant interface scan state tracking

[Daniel Drake]

On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote:
> It could be a signal ordering issue.  The code in
> nm-supplicant-interface.c is:
> 
>   if (priv->scanning)
>   return TRUE;
>   if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING)
>   return TRUE;
> 
> So only if both of these are FALSE will
> nm_supplicant_interface_get_scanning() return FALSE.  Each of these
> variables is independently set, priv->scanning is based off the
> supplicant's 'scanning' property, and priv->con_state is based off the
> 'state' property.

The problem is that sometimes when this happens, con_state is never
updated. It remains as SCANNING even after eth0 has been disconnected.
Would it be OK to reset this to 0 inside disconnect_cb?

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

supplicant interface scan state tracking

[Daniel Drake]

Hi Dan,

I'm finding it quite easy to reproduce a bug related to
nm_supplicant_interface_get_scanning()
but I'm not sure how to fix it.

The logic implemented in my OLPC mesh device so-far is that if the
companion device is scanning, it postpones stage2 until the scanning has
finished.

It does this by monitoring a new "scanning" property on NMDeviceWifi
which is implemented based on nm_supplicant_interface_get_scanning().
http://dev.laptop.org/git/users/dsd/NetworkManager/commit/?h=olpc&id=111baac88318f4db467360fd9703f37ac0449023

Also, if a connection on eth0 is active when you activate a msh0
connection, msh0 moves eth0 into NM_DEVICE_STATE_DISCONNECTED and
disables autoconnect (via the mechanism in the patch I emailed earlier).

Anyway, I can now easily reproduce the following sequence of events
causing nm_supplicant_interface_get_scanning() to be less than truthful
and cause a deadlock:

to start with, an eth0 connection is activating:

  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
  Config: set interface ap_scan to 1

at this point, inside NMDeviceOlpcMeshPrivate, "scanning" is TRUE and
con_state = SCANNING (I know this through some debug messages)

  (eth0): supplicant connection state:  disconnected -> scanning

but I interrupt it here by starting a mesh connection

  Activation (msh0) starting connection 'olpc-mesh-1'
  (msh0): device state change: 3 -> 4 (reason 0)
  Activation (msh0) Stage 1 of 5 (Device Prepare) scheduled...
  Activation (msh0) Stage 1 of 5 (Device Prepare) started...

msh0 now disconnects eth0

  (eth0): device state change: 5 -> 3 (reason 2)
  (eth0): deactivating device (reason: 2).
  Activation (msh0) Stage 1 of 5 (Device Prepare) complete.

At this point, another dbus signal comes in from wpa_supplicant so
"scanning" moves to FALSE. This wakes up msh0 device which calls
nm_supplicant_interface_get_scanning() to figure out the new state, but
this returns TRUE because con_state is still SCANNING, so msh0 does not
continue the connection process and everything stops.

What confuses me a little here is that the supplicant is still alive and
running, even though there aren't any active connections. It did also
manage to raise a dbus signal indicating the termination of the scan
*after* NM sent the disconnection request, but it did not manage to
communicate any change in con_state. Also I cannot connect to it with
wpa_cli to see if is still in SCANNING state.

Thoughts?

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Sugar + OLPC mesh network selection logic

[Daniel Drake]

On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> If other APs appear later, it may well trigger the
> schedule_activate_check() which might cause NM to try to connect to that
> new network.  To combat that, I'd suggest that the mesh device block the
> wifi device from activating if it already failed by putting it into the
> UNAVAILABLE state or something, but that could be error prone.  What I
> think we really want here is the 'device idle' concept that asac and I
> have been talking over for a while.

The same consideration has to apply for when the mesh device disconnects
the eth device, because the user requested a mesh connection. Right now,
NM immediately reactivates eth0 (usually reconnecting to the same
network as before) and "wins."

What is the "device idle" concept? What do you think of an approach
along these lines? This way the mesh device can attach to the
autoconnect-allowed signal on the main device, and influence when it can
and cannot be used for automatic connections.

Daniel

>From bf78fa416ecf96bf9e607d1dd7c8fec29652a821 Mon Sep 17 00:00:00 2001
From: Daniel Drake 
Date: Mon, 6 Jul 2009 16:42:55 +0100
Subject: [PATCH] Allow devices to inhibit autoconnect through a signal

This allows a device (or a companion) to signal that it is not a good
time for a specific device to autoconnect to a network.
---
 src/NetworkManagerPolicy.c |2 +-
 src/nm-device.c|   45 
 src/nm-device.h|1 +
 3 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/src/NetworkManagerPolicy.c b/src/NetworkManagerPolicy.c
index 6bba92f..e2d4c95 100644
--- a/src/NetworkManagerPolicy.c
+++ b/src/NetworkManagerPolicy.c
@@ -726,7 +726,7 @@ schedule_activate_check (NMPolicy *policy, NMDevice *device)
 	if (state < NM_DEVICE_STATE_DISCONNECTED)
 		return;
 
-	if (!nm_device_can_activate (device))
+	if (!nm_device_can_activate (device) || !nm_device_autoconnect_allowed (device))
 		return;
 
 	for (iter = policy->pending_activation_checks; iter; iter = g_slist_next (iter)) {
diff --git a/src/nm-device.c b/src/nm-device.c
index 5826a2a..488b2cf 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -50,11 +50,19 @@
 #include "nm-setting-connection.h"
 #include "nm-dnsmasq-manager.h"
 #include "nm-dhcp4-config.h"
+#include "nm-marshal.h"
 
 #define NM_ACT_REQUEST_IP4_CONFIG "nm-act-request-ip4-config"
 
 static void device_interface_init (NMDeviceInterface *device_interface_class);
 
+enum {
+	AUTOCONNECT_ALLOWED,
+	LAST_SIGNAL,
+};
+
+static guint signals[LAST_SIGNAL] = { 0 };
+
 G_DEFINE_TYPE_EXTENDED (NMDevice, nm_device, G_TYPE_OBJECT,
 		G_TYPE_FLAG_ABSTRACT,
 		G_IMPLEMENT_INTERFACE (NM_TYPE_DEVICE_INTERFACE,
@@ -360,6 +368,34 @@ nm_device_can_activate (NMDevice *self)
 	return TRUE;
 }
 
+static gboolean
+autoconnect_allowed_accumulator (GSignalInvocationHint *ihint,
+ GValue *return_accu,
+ const GValue *handler_return, gpointer data)
+{
+	if (!g_value_get_boolean (handler_return))
+		g_value_set_boolean (return_accu, FALSE);
+	return TRUE;
+}
+
+gboolean
+nm_device_autoconnect_allowed (NMDevice *self)
+{
+	GValue instance = { 0, };
+	GValue retval = { 0, };
+
+	g_value_init (&instance, G_TYPE_OBJECT);
+	g_value_take_object (&instance, self);
+
+	g_value_init (&retval, G_TYPE_BOOLEAN);
+	g_value_set_boolean (&retval, TRUE);
+
+	/* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
+	 * value being changed if no handlers are connected */
+	g_signal_emitv (&instance, signals[AUTOCONNECT_ALLOWED], 0, &retval);
+	return g_value_get_boolean (&retval);
+}
+
 NMConnection *
 nm_device_get_best_auto_connection (NMDevice *dev,
 GSList *connections,
@@ -2380,6 +2416,15 @@ nm_device_class_init (NMDeviceClass *klass)
 	g_object_class_override_property (object_class,
 	  NM_DEVICE_INTERFACE_PROP_MANAGED,
 	  NM_DEVICE_INTERFACE_MANAGED);
+
+	signals[AUTOCONNECT_ALLOWED] =
+		g_signal_new ("autoconnect-allowed",
+		  G_OBJECT_CLASS_TYPE (object_class),
+		  G_SIGNAL_RUN_LAST,
+		  0,
+		  autoconnect_allowed_accumulator, NULL,
+		  _nm_marshal_BOOLEAN__VOID,
+		  G_TYPE_BOOLEAN, 0);
 }
 
 static gboolean
diff --git a/src/nm-device.h b/src/nm-device.h
index 9084816..b230da8 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -159,6 +159,7 @@ void			nm_device_activate_schedule_stage4_ip_config_timeout	(NMDevice *device);
 gboolean		nm_device_deactivate_quickly	(NMDevice *dev);
 gboolean		nm_device_is_activating		(NMDevice *dev);
 gboolean		nm_device_can_interrupt_activation		(NMDevice *self);
+gboolean		nm_device_autoconnect_allowed	(NMDevice *self);
 
 NMDeviceState nm_device_get_sta

Re: interactions between OLPC wifi and mesh interfaces

[Daniel Drake]

On Wed, 2009-06-10 at 17:37 +0100, Peter Robinson wrote:
> In the basic testing I've done on 8.2.1 I'm  not sure it disconnects
> from the mesh when connecting to a standard network. I had problems
> when connecting to my AP until I worked out I had to put the mesh on
> the same channel as my AP. Once I did that I could connect to the AP
> fine but the mesh channel still throbbed in the Neighbourhood to show
> it was on that connection.

You're right, there are some reliability bugs in the old code there --
it doesn't always work. And sometimes you end up with a confusing state
on the network view like you are seeing. I hope to lose these bugs in
the new NM/sugar code, hence me asking for implementation advice.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

interactions between OLPC wifi and mesh interfaces

[Daniel Drake]

Hi,

I'm a little stuck with one issue reimplementing the OLPC mesh device
support.

1. When the user is connected to a standard network through eth0, and
then they request a connection to a mesh network on msh0, eth0 should
disconnect and go quiet before the mesh connection starts to happen.

2. When the user is on a mesh through msh0 and requests connection to a
real network through eth0, the mesh should disconnect itself.

How was this implemented in the NM-0.6 solution? It seemed to work
there.


For (1) I added code into stage1_prepare in the mesh device. It checks
to see if the companion is activated, if so it calls
nm_device_state_changed() to make it NM_DEVICE_STATE_DISCONNECTED.

This almost works. I connect to an IBSS, and then the mesh. The above
code disconnects from the IBSS and starts the mesh connection process.
However NM is still treating the devices as separate, so very quickly it
tries to look for a connection to apply to eth0 again. It finds the same
one (which Sugar's settings implementation is advertising as a network
that should be autoconnected to) and then we end up with a mess where
we're trying to connect to a mesh and an IBSS simultaneously.

Switching eth0 to NM_DEVICE_STATE_UNAVAILABLE didn't help, it just got
back on its feet in the same way.

Thoughts?


No problems (yet) with (2). I connected a signal to the companion device
state-changed within the mesh device. If the companion is moving into an
active state, and the mesh device is active, I use
nm_device_state_changed() to disconnect the mesh device. This works, at
least while sugar is not offering an autoconnect mesh network setting.

I've attached my patch which may help to explain the above situation.

Thanks,
Daniel

diff --git a/src/nm-device-olpc-mesh.c b/src/nm-device-olpc-mesh.c
index 41056d6..3c7aea8 100644
--- a/src/nm-device-olpc-mesh.c
+++ b/src/nm-device-olpc-mesh.c
@@ -694,7 +694,16 @@ real_act_stage1_prepare (NMDevice *dev, 
NMDeviceStateReason *reason)
 {
NMDeviceOlpcMeshPrivate *priv = NM_DEVICE_OLPC_MESH_GET_PRIVATE (dev);
 
-   /* wait with continueing configuration untill the companion device is 
done
+   /* disconnect companion device, if it is connected */
+   if (nm_device_get_act_request (NM_DEVICE (priv->companion))) {
+   nm_warning("disconnecting companion device");
+   nm_device_state_changed (NM_DEVICE (priv->companion),
+NM_DEVICE_STATE_UNAVAILABLE,
+
NM_VPN_CONNECTION_STATE_REASON_USER_DISCONNECTED);
+   nm_warning("companion disconnected");
+   }
+
+   /* wait with continuing configuration untill the companion device is 
done
 * scanning */
if (nm_device_wifi_is_scanning (NM_DEVICE_WIFI (priv->companion))) {
priv->stage1_waiting = TRUE;
@@ -888,6 +897,25 @@ companion_notify_cb (NMDeviceWifi *companion, GParamSpec 
*pspec, gpointer user_d
}
 }
 
+/* disconnect from mesh if someone starts using the companion */
+static void
+companion_state_changed_cb (NMDeviceWifi *companion, NMDeviceState state, 
NMDeviceState old_state, NMDeviceStateReason reason, gpointer user_data)
+{
+   NMDeviceOlpcMesh *self = NM_DEVICE_OLPC_MESH (user_data);
+   NMDeviceState self_state = nm_device_get_state (NM_DEVICE (self));
+
+   if (self_state < NM_DEVICE_STATE_PREPARE
+   || self_state > NM_DEVICE_STATE_ACTIVATED
+   || state < NM_DEVICE_STATE_PREPARE
+   || state > NM_DEVICE_STATE_ACTIVATED)
+   return;
+
+   nm_debug ("disconnecting mesh due to companion connectivity");
+   nm_device_state_changed (NM_DEVICE (self),
+NM_DEVICE_STATE_DISCONNECTED,
+
NM_VPN_CONNECTION_STATE_REASON_USER_DISCONNECTED);
+}
+
 static gboolean
 companion_scan_allowed_cb (NMDeviceWifi *companion, gpointer user_data)
 {
@@ -930,10 +958,13 @@ is_companion (NMDeviceOlpcMesh *self, NMDevice *other)
 
nm_debug ("Found companion device: %s", nm_device_get_iface (other));
 
-   g_signal_connect (G_OBJECT(other), "notify::scanning",
-   G_CALLBACK(companion_notify_cb), self);
-   g_signal_connect (G_OBJECT(other), "scanning-allowed",
-   G_CALLBACK(companion_scan_allowed_cb), self);
+   /* FIXME: where to disconnect? */
+   g_signal_connect (G_OBJECT (other), "state-changed",
+   G_CALLBACK (companion_state_changed_cb), self);
+   g_signal_connect (G_OBJECT (other), "notify::scanning",
+   G_CALLBACK (companion_notify_cb), self);
+   g_signal_connect (G_OBJECT (other), "scanning-allowed",
+   G_CALLBACK (companion_scan_allowed_cb), self);
 
return TRUE;
 }
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networ

Sugar + OLPC mesh network selection logic

[Daniel Drake]

Hi,

I'm looking to implement network selection logic in sugar-0.84 using the
NetworkManager D-Bus API to implement something similar to what was
present in NetworkManager-0.6 for OLPC's mesh device. (the logic is now
being moved out of NetworkManager into sugar)

My work in progress is:
NM-0.7 with OLPC mesh support
http://dev.laptop.org/git/users/dsd/NetworkManager/log/?h=olpc
http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi
sugar-0.84.5 patch to add mesh support (connects to link local mesh when
selected on neighborhood view)
http://dev.laptop.org/~dsd/20090610/sugar-0.84-olpc-mesh.patch


I'm looking for some feedback on my plan, particularly for the
interacting-with-NM side of things.

This is how sugar works at the moment (I think):
- Only infrastructure networks are supported.
- On a new install, it doesn't attempt any connections.
- When the user clicks on a network to connect, sugar makes an
NMSettingsConnection object and and uses ActivateConnection() to
activate it.
- If the connection succeeds, sugar saves the details internally.

- When starting up again later, sugar loads all its saved networks,
creating NMSettingsConnection objects with the autoconnect flag set.
- It doesn't call ActivateConnection() on anything, but presumably NM
notices the new connections (with the autoconnect preference) and picks
one to try.


And now the logic I want to implement, which is similar to that in
previous OLPC OS releases:
- First, attempt to connect to any known access points that are in range
using saved credentials. Always prefer known APs to mesh.
- As a fallback if those APs fail, or if no APs are available or if
we've never connected to any (e.g. on first boot), try the mesh.

"try the mesh" means trying each of these configurations in turn,
stopping on the first one that succeeds:
1. Connect to school server on channel 1 (i.e. dhcp with XS anycast
address)
2. Connect to mesh portal on channel 1 (i.e. dhcp with MPP anycast
address)
3. Connect to school server on channel 6
4. Connect to mesh portal on channel 6
5. Connect to school server on channel 11
6. Connect to mesh portal on channel 11
7. Connect to link-local simple mesh on channel 1 (cannot fail)

[the mesh device settings class has properties 'channel' and
'dhcp-anycast-address' therefore the way to try each configuration is by
creating and activating a new NMSettingsConnection object for each one]

My uncertainty is how to implement the above logic.

Is it possible to assign a priority or preference to a
NMSettingsConnection object? If so, I could just create high-priority
objects for all APs, and decreasing priority objects for the mesh
configurations, all with the autoconnect flag. The priorities would
cause Networkmanager to try them in order suggested above.

Alternatively, we could always set autoconnect=False for all networks,
and have some kind of management layer inside sugar which iterates
through all the networks, monitoring the device states, calling
ActivateConnection and moving onto the next one if it failed to connect.
But immediately it gets tricky.. for infrastructure networks, we have to
consider which APs are available, and what happens if they appear
later?, etc.

Or, other options?

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

reviving OLPC & NetworkManager-0.7 work

[Daniel Drake]

Hi,

I'm working to get the OLPC mesh interface working with new
NetworkManager releases and to get suitable code upstream. I would also
like to get this backported into Fedora 11 for OLPC's XO-1.5 software
build.

What is the suggested approach I should take here?

Should I work with git master and then backport to 0.7 after? (how
usable is that? how much trouble can I expect trying to get it
operational on F11 for development purposes?)

I'm aware of Sjoerd Simon's previous work, and have looked over the
discussion that resulted on the last set of submitted patches.

So far I have taken his work, and reworked the patches based on the
earlier feedback and recent NM changes, against 0.7 HEAD:
git://dev.laptop.org/users/dsd/NetworkManager branch "olpc"
http://dev.laptop.org/git/users/dsd/NetworkManager/log/?h=olpc

I've also done some basic tests on an XO, it is working.

Dan, I'd also appreciate it if you could take a very quick look at the
style of the OLPC mesh device implementation:
http://dev.laptop.org/git/users/dsd/NetworkManager/commit/?h=olpc&id=4b5095bdb843667eba215d15232cdfd5c27f53be
There are rough edges and FIXMEs to be handled, but it would be nice to
know whether we are on the right lines for an upstream-acceptable
implementation or not.

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NMSupplicantInterface PROP_CONNECTION_STATE not installed

[Daniel Drake]

On Fri, 2009-06-05 at 14:35 -0400, Dan Williams wrote:
> It really shouldn't; I was being conservative there.  The 'scanning'
> property (assuming you have that supplicant patch which is now upstream
> and also available at [1]) should reflect the scanning state internally
> in the supplicant.

OK, makes sense, and if it doesn't then we should fix the supplicant.
So I don't think there is a need for any patches here.

Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NMSupplicantInterface PROP_CONNECTION_STATE not installed

[Daniel Drake]

On Fri, 2009-06-05 at 09:16 -0400, Dan Williams wrote:
> How about using the 'scanning' property instead?  That's exactly what
> the 'scanning' property is for, and connection-state doesn't always
> reflect when the supplicant is actually scanning (ie, it won't back down
> from CONNECTED -> SCANNING when it's associated but can't find the AP in
> an unsolicited scan list, but will direct-scan again anyway), which is
> why I added the 'scanning' property and associated patch to
> wpa_supplicant.  Will that do what you need?

I don't know.

I need a "subscribable" way of monitoring "is this interface currently
scanning for networks." I found the function
nm_supplicant_interface_get_scanning() which reflects both the
"scanning" property (which is subscribable, great), and the
"connection-state" property (which only half exists).

If I'm to believe the logic in that function, I need to subscribe to
both "scanning" and "connection-state". The function seems to suggest
that sometimes, priv->scanning will be FALSE even though the connection
state is NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING.

Thanks,
Daniel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NMSupplicantInterface PROP_CONNECTION_STATE not installed

[Daniel Drake]

On Fri, 2009-06-05 at 11:26 +0100, Daniel Drake wrote:
> Hi,
> 
> The PROP_CONNECTION_STATE property on NMSupplicantInterface
> (src/supplicant-manager/nm-supplicant-interface.c) seems not to be
> installed through g_object_class_install_property(), hence is not
> really usable.

possible patch, compile tested only

Daniel

>From 41b84dffe018e764dd7571ad10be42c1c4a7f511 Mon Sep 17 00:00:00 2001
From: Daniel Drake 
Date: Fri, 5 Jun 2009 12:05:13 +0100
Subject: [PATCH] NMSupplicantInterface: make PROP_CONNECTION_STATE a real 
property

It now generates notify events when the property changes.
---
 src/supplicant-manager/nm-supplicant-interface.c |   17 +++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/supplicant-manager/nm-supplicant-interface.c 
b/src/supplicant-manager/nm-supplicant-interface.c
index 32bbdfa..eff9ea2 100644
--- a/src/supplicant-manager/nm-supplicant-interface.c
+++ b/src/supplicant-manager/nm-supplicant-interface.c
@@ -395,6 +395,16 @@ nm_supplicant_interface_class_init 
(NMSupplicantInterfaceClass *klass)
G_PARAM_READABLE));
 
g_object_class_install_property (object_class,
+PROP_CONNECTION_STATE,
+g_param_spec_uint ("connection-state",
+   "Connection state",
+   "Connection state",
+   
NM_SUPPLICANT_INTERFACE_CON_STATE_DISCONNECTED,
+   
NM_SUPPLICANT_INTERFACE_CON_STATE_LAST - 1,
+   
NM_SUPPLICANT_INTERFACE_CON_STATE_DISCONNECTED,
+   G_PARAM_READABLE));
+
+   g_object_class_install_property (object_class,
 PROP_SCANNING,
 g_param_spec_boolean ("scanning",
"Scanning",
@@ -640,6 +650,7 @@ wpas_iface_handle_state_change (DBusGProxy *proxy,
enum_new_state = wpas_state_string_to_enum (str_new_state);
old_state = priv->con_state;
priv->con_state = enum_new_state;
+   g_object_notify (G_OBJECT (user_data), "connection-state");
if (priv->con_state != old_state) {
g_signal_emit (user_data,
   
nm_supplicant_interface_signals[CONNECTION_STATE],
@@ -663,11 +674,13 @@ iface_state_cb (DBusGProxy *proxy, DBusGProxyCall 
*call_id, gpointer user_data)
g_error_free (err);
} else {
NMSupplicantInfo *info = (NMSupplicantInfo *) user_data;
-   NMSupplicantInterfacePrivate *priv = 
NM_SUPPLICANT_INTERFACE_GET_PRIVATE (info->interface);
+   NMSupplicantInterface *iface = info->interface;
+   NMSupplicantInterfacePrivate *priv = 
NM_SUPPLICANT_INTERFACE_GET_PRIVATE (iface);
 
priv->con_state = wpas_state_string_to_enum (state_str);
+   g_object_notify (G_OBJECT (iface), "connection-state");
g_free (state_str);
-   nm_supplicant_interface_set_state (info->interface, 
NM_SUPPLICANT_INTERFACE_STATE_READY);
+   nm_supplicant_interface_set_state (iface, 
NM_SUPPLICANT_INTERFACE_STATE_READY);
}
 }
 
-- 
1.6.2.2

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

NMSupplicantInterface PROP_CONNECTION_STATE not installed

[Daniel Drake]

Hi,

The PROP_CONNECTION_STATE property on NMSupplicantInterface
(src/supplicant-manager/nm-supplicant-interface.c) seems not to be
installed through g_object_class_install_property(), hence is not
really usable.

I'm interested in it being a usable property so that I can attach a
"notify" handler to the object and receive notification on when it
changes (also have to add some g_object_notify() calls in that file
appropriately when con_state changes). Or should I subscribe to the
connection-state signal instead, which seems to do that?


The background is that I'm trying to act on this feedback:
http://thread.gmane.org/gmane.linux.network.networkmanager.devel/10398/focus=10422

As things have changed around a bit, I'm now trying to expose a
"scanning" property from NMDeviceWifi which other code (i.e. mesh
device implementation) can then monitor for notify events in order to
know when scanning has started or finished. This means that I
effectively need to reimplement the
nm_supplicant_interface_get_scanning() logic as a property in
NMDeviceWifi: generate a property change notification when
NMSupplicantInterface's "scanning" property changes, *or* when
NMSupplicantInterface's half-existant "connection-state" property
changes.

Daniel
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list