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
On Thu, Sep 5, 2013 at 4:05 PM, Dan Williams d...@redhat.com 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:
On Thu, May 9, 2013 at 5:19 PM, Dan Williams d...@redhat.com 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
On Fri, May 10, 2013 at 12:14 PM, Dan Williams d...@redhat.com 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
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,
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
On Tue, Dec 11, 2012 at 9:46 AM, Daniel Drake d...@laptop.org 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
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
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
On Fri, Nov 25, 2011 at 9:10 AM, Daniel Drake d...@laptop.org 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
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../..
On Tue, Sep 6, 2011 at 10:54 PM, Dan Williams d...@redhat.com 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
On Tue, Sep 6, 2011 at 11:20 PM, Dan Williams d...@redhat.com 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
On Sun, Sep 4, 2011 at 8:12 PM, Sascha Silbe si...@activitycentral.com 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
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
Bump :)
On 9 July 2010 15:58, Daniel Drake d...@laptop.org 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
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
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
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.
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:
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
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
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
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,
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
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:
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
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
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():
2009/9/18 Daniel Drake d...@laptop.org:
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
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
---
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
@@
---
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
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
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
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 +-
+ * Sjoerd Simons sjoerd.sim...@collabora.co.uk
+ * Daniel Drake d...@laptop.org
+ *
+ * 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
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.
: C; tab-width: 5; indent-tabs-mode: t; c-basic-offset: 5 -*- */
+
+/*
+ * Dan Williams d...@redhat.com
+ * Tambet Ingo tam...@gmail.com
+ * Sjoerd Simons sjoerd.sim...@collabora.co.uk
+ * Daniel Drake d...@laptop.org
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify
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
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*,
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
+++
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
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
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
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
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
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
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
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,
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 ++-
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 +-
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
-offset: 5 -*- */
+
+/*
+ * Dan Williams d...@redhat.com
+ * Tambet Ingo tam...@gmail.com
+ * Sjoerd Simons sjoerd.sim...@collabora.co.uk
+ * Daniel Drake d...@laptop.org
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
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;
-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 d...@laptop.org
Date: Mon, 6 Jul 2009 16:42:55 +0100
Subject: [PATCH] Allow devices to inhibit
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
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
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.
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
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
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
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
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,
63 matches
Mail list logo
