Re: is there anyone here who understands the vpn implementation

2010-11-04 Thread Daniel Wagner 
Hi Thomas,

On Wed, Nov 03, 2010 at 10:01:27AM -0700, Thomas Bushnell, BSG wrote:
> I've asked a few questions and gotten deafening silence. I'm not a bozo, and
> I was hoping for slightly more.
> 
> Is there anyone here who understands the VPN plugin implementation in
> network manager?

I have looked into the way NM handles this. If I got it right it works
like this: For each type of VPN implementation (e.g. openvpn) there
exists a helper daemon which exports an D-Bus interface. The helper
VPN daemon is spawnding the real VPN deamon. In the case of OpenVPN it
will start the daemon with few general arguments (e.g. client mode
etc) and a script argument ('--up') which will be called when OpenVPN
changes state (e.g. gets connected). The script called by OpenVPN is a
callback function into the VPN helper daemon which results into an
D-Bus message to NM.

> Is it necessary for a VPN plugin to allow network manager to manage the
> routing and tunneling once the VPN is setup, or is it ok if the VPN plugin
> does that itself?

OpenVPN is started with --route-noexec and --ifconfig-noexec which
means the OpenVPN is not change anything concerning routing or IP
configuration.

> What is the mechanism by which the VPN plugin should communicate to network
> manager that the connection is live? nm_vpn_plugin_set_state (...,
> NM_VPN_SERVICE_STATE_STARTED) does not work, and the vpnc plugin doesn't
> even do that much, yet of course it works.

Haven't looked at that part.

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

Re: Is accounting supported?

2010-01-17 Thread Daniel Wagner 

Hi Dan,


Just out of curiosity: where does the accounting information come from?
I see one possible solution using netfilter with ULOG target and the
ulogd daemon.

I guess when using ulogd there is always a certain lag between the
number of bytes transferred/received and the user defined maximum of
bytes transferred/received (probably enforced by PolicyKit). I don't
think that's a real problem and could be workaround if there isn't the
need to have exact numbers.


At least for PPP we can get traffic counts via ioctls.  I'd like to get
traffic counts for the other devices like ifconfig does, but last I knew
ifconfig got that by scraping /proc/net/dev which is just ugly.  We may
be able to get updated traffic counts from netlink somehow?


I tried to figure out how a generic solution would look like and the 
solution I found was the thing with the ULOG trick. The kernel interface 
to netfilter is netlink based and the ulogd daemon uses this API. Though 
I'm not so sure if the authors recommand to use this API. IRC the 
iptables API should not be used directly.


daniel

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

Re: Is accounting supported?

2010-01-12 Thread Daniel Wagner 

On 01/07/2010 05:27 PM, Dan Williams wrote:

On Thu, 2010-01-07 at 08:18 +, Alex Buell wrote:

On Wed, 2010-01-06 at 22:51 -0800, Dan Williams wrote:

On Tue, 2010-01-05 at 14:31 +0530, Elison Niven wrote:

Hi List,

I am using Network manager with Gnome network applet on Fedora 12.

Are there any options for getting accounting like information about connect
times, data bytes in and out etc?


Not yet, but I've been trying to get somebody interested in doing the
feature since I'm swamped with a bunch of other stuff at this point.  It
shouldn't be too bad; we just keep a sqlite database around of all
connection start/stop/bytecounts and then expose that as a D-Bus
interface that applets can read.  Either somebody needs to step up or I
guess just wait until I get around to it.


I'd like to volunteer to do this. I'll get around to it over the weekend
and send you patches if you like. All I need is a list of desired
features and I'll implement it. Just my way of contributing to NM!


Excellent!  I put a summary of what I think should be done here:

https://bugzilla.gnome.org/show_bug.cgi?id=601372

Does the stuff in Comment #3 sound doable?  You don't have to do
everything at the start but we can do it incrementally.  Like you don't
need to populate the "user-id" and "user-name" fields yet, since we need
to do a bit more internally to NM to store that information in the
NMActRequest structure (by pulling the uid off the D-Bus request to
start the connection).

Let me know if you have any questions.


Just out of curiosity: where does the accounting information come from? 
I see one possible solution using netfilter with ULOG target and the 
ulogd daemon.


I guess when using ulogd there is always a certain lag between the 
number of bytes transferred/received and the user defined maximum of 
bytes transferred/received (probably enforced by PolicyKit). I don't 
think that's a real problem and could be workaround if there isn't the 
need to have exact numbers.


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

Re: NetworkManager and mac80211_hwsim

2009-02-20 Thread Daniel Wagner 
As it seems some more tweaking was needed to get it running
with the current HAL head. Does this work for you?

daniel

---

NetworkManager wants to read info.linux.driver for all devices.
Since a mac80211_hwsim device doesn't have a real parent the
property is not added. So let's add this property if there
is no proper parent and it is a 80211 device.

Signed-off-by: Daniel Wagner 

---
v2: Set address for wmaster devices to nil. Otherwise the real
networking device is overwritten.

 hald/linux/device.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/hald/linux/device.c b/hald/linux/device.c
index 21b9176..83b4a30 100644
--- a/hald/linux/device.c
+++ b/hald/linux/device.c
@@ -1576,6 +1576,7 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
guint media_type;
gint flags;
gint addr_len;
+   gboolean real_parent = TRUE;
 
d = NULL;
d = hal_device_new ();
@@ -1588,6 +1589,7 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
HAL_ERROR (("Device '%s' has no parent and 
couldn't find computer root object."));
goto error;
}
+   real_parent = FALSE;
}
 }
 
@@ -1662,6 +1664,11 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
hal_device_property_set_string (d, "info.category", 
"net.80211");
hal_device_add_capability (d, "net.80211");
hal_device_property_set_uint64 (d, 
"net.80211.mac_address", mac_address);
+
+   if (!real_parent) {
+   /* This is must be a mac80211_hwsim device */
+   hal_device_property_set_string (parent_dev, 
"info.linux.driver", "mac80211_hwsim");
+   }
} else if (stat (bridge_path, &s) == 0 && (s.st_mode & 
S_IFDIR)) {
hal_device_property_set_string (d, "info.product", 
"Bridge Interface");
hal_device_property_set_string (d, "info.category", 
"net.bridge");
@@ -1691,6 +1698,7 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
hal_device_property_set_string (d, "info.product", "Networking 
Wireless Control Interface");
hal_device_property_set_string (d, "info.category", 
"net.80211control");
hal_device_add_capability (d, "net.80211control");
+   hal_device_property_set_string (d, "net.address", 
"00:00:00:00:00:00");
}
 #else
 #warning ARPHRD_IEEE80211_RADIOTAP and/or ARPHRD_IEEE80211_PRISM not defined!
-- 
1.6.0.2.GIT

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

Re: NetworkManager and mac80211_hwsim

2009-02-19 Thread Daniel Wagner 
On Thu, Feb 19, 2009 at 04:17:06PM +0200, Kevin Wilson wrote:
> Hello,
> 
> Can you please tell against which version of hal source you
> made this patch ? I tried it against the hal sources in my
> fedora distro and got errors when patching.

Argh, I'm stupid. I created the patch against the last 0.5.11 release.
I didn't see there is a 0.5.12rc on the fly. Anyway here is a new
version against the head. I think it could be send upstream. It doesn`t
look that bad anymore. What do you think?

daniel

---

>From 14c76a6642a1ed4f93b6dfed96af6d7513102c88 Mon Sep 17 00:00:00 2001
From: Daniel Wagner 
Date: Thu, 19 Feb 2009 18:14:09 +0100
Subject: [PATCH] Add info.linux.driver property for mac80211_hwsim devices

NetworkManager wants to read info.linux.driver for all devices.
Since a mac80211_hwsim device doesn't have a real parent the
property is not added. So let's add this property if there
is no proper parent and it is a 80211 device.

Signed-off-by: Daniel Wagner 
---
 hald/linux/device.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/hald/linux/device.c b/hald/linux/device.c
index 21b9176..b68d3ef 100644
--- a/hald/linux/device.c
+++ b/hald/linux/device.c
@@ -1576,6 +1576,7 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
guint media_type;
gint flags;
gint addr_len;
+   gboolean real_parent = TRUE;
 
d = NULL;
d = hal_device_new ();
@@ -1588,6 +1589,7 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
HAL_ERROR (("Device '%s' has no parent and 
couldn't find computer root object."));
goto error;
}
+   real_parent = FALSE;
}
 }
 
@@ -1662,6 +1664,11 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
hal_device_property_set_string (d, "info.category", 
"net.80211");
hal_device_add_capability (d, "net.80211");
hal_device_property_set_uint64 (d, 
"net.80211.mac_address", mac_address);
+
+   if (!real_parent) {
+   /* This is must be a mac80211_hwsim device */
+   hal_device_property_set_string (parent_dev, 
"info.linux.driver", "mac80211_hwsim");
+   }
} else if (stat (bridge_path, &s) == 0 && (s.st_mode & 
S_IFDIR)) {
hal_device_property_set_string (d, "info.product", 
"Bridge Interface");
hal_device_property_set_string (d, "info.category", 
"net.bridge");
-- 
1.6.0.2.GIT

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

Re: NetworkManager and mac80211_hwsim

2009-02-18 Thread Daniel Wagner 
On Wed, Feb 18, 2009 at 09:35:59AM +0100, Johannes Berg wrote:
> On Wed, 2009-02-18 at 09:06 +0100, Daniel Wagner wrote:
> 
> > +   if (parent_dev != NULL) {
> > +   hal_device_property_set_string (d, "info.parent", 
> > hal_device_get_udi (parent_dev));
> > +   hal_device_property_set_string (d, "net.originating_device", 
> > hal_device_get_udi (parent_dev));
> > +   } else {
> > +   hal_device_property_set_string (d, "info.parent", 
> > "/org/freedesktop/Hal/devices/computer");
> > +   hal_device_property_set_string (d, "net.originating_device", 
> > "/org/freedesktop/Hal/devices/computer");
> > +   hal_device_property_set_string (d, "info.linux.driver", 
> > "mac80211_hwsim");
> > +   parent_dev = hal_device_store_find (hald_get_gdl (), 
> > "/org/freedesktop/Hal/devices/computer");
> > +   hal_device_property_set_string (parent_dev, 
> > "info.linux.driver", "mac80211");
> > +   }
> 
> This is actually not _that_ bad an idea, because it makes sure everybody
> else will properly link up their parent pointer in sysfs. 

That was exactly the problem. HAL creates only a 'correct' dbus tree if the
sysfs parent pointers exists. The patch just fakes the parent 'computer'.
This 'computer' node holds all parent-less nodes (eg alsa_sequencer, 
alsa_timer).
One further problem is that the 'computer' node doesn't have a 
'info.linux.driver'
property which NM wants to read. Setting this property to 'mac80211' is
not correct for all children of this node.

> An alternative
> that doesn't guarantee that would be to check "is it in the ieee80211
> class".

At the moment NM wants a proper parent->child construct to work. Adding 
something like
/org/freedesktop/Hal/devices/virtual/mac80211_hwsim as parent for the child
would propably be a solution. As I said I was not really ready for fixing
this up. But if this is something worth to fix I'll do it.

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

Re: NetworkManager and mac80211_hwsim

2009-02-18 Thread Daniel Wagner 
On Mon, Feb 16, 2009 at 01:00:51PM -0500, Dan Williams wrote:
> On Mon, 2009-02-16 at 18:25 +0100, Daniel Wagner wrote:
> > On Mon, Feb 16, 2009 at 05:04:44PM +0100, Johannes Berg wrote:
> > > On Mon, 2009-02-16 at 17:00 +0100, Daniel Wagner wrote:
> > > 
> > > > hotplug_event_begin_add_dev (..., parent_dev = NULL, ...)
> > > >   net_add(..., parent_dev = NULL, ...)
> > > >   {
> > > > if (parent_dev == NULL)
> > > > goto error;
> > > >   }
> > > > 
> > > > Before I go deeper into that thing, does someone has
> > > > an idea what could go wrong here with mac80211_hwsim?
> > > 
> > > hwsim phys have no parents in sysfs since they're virtual.
> > 
> > Do you propose to patch hald to handle this situation then?
> 
> The patch (for now) would have to go in hal, since obviously if HAL
> can't see it, NM won't.  Until we port over to DeviceKit of course.

Thanks for the information. After looking at HAL for a while and 
knowing that it will be replaced in the near future I decided 
not to write a proper patch. Instead I came up with a big hack. 
With this hack NM sees the mac80211_hwsim devices :)

daniel

---
 hald/linux/device.c |   23 +--
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/hald/linux/device.c b/hald/linux/device.c
index e48548e..699d26b 100644
--- a/hald/linux/device.c
+++ b/hald/linux/device.c
@@ -497,20 +497,22 @@ net_add (const gchar *sysfs_path, const gchar 
*device_file, HalDevice *parent_de
guint media_type;
gint flags;
 
-   d = NULL;
-
-   if (parent_dev == NULL)
-   goto error;
-
d = hal_device_new ();
hal_device_property_set_string (d, "linux.sysfs_path", sysfs_path);
-   hal_device_property_set_string (d, "info.parent", hal_device_get_udi 
(parent_dev));
+   if (parent_dev != NULL) {
+   hal_device_property_set_string (d, "info.parent", 
hal_device_get_udi (parent_dev));
+   hal_device_property_set_string (d, "net.originating_device", 
hal_device_get_udi (parent_dev));
+   } else {
+   hal_device_property_set_string (d, "info.parent", 
"/org/freedesktop/Hal/devices/computer");
+   hal_device_property_set_string (d, "net.originating_device", 
"/org/freedesktop/Hal/devices/computer");
+   hal_device_property_set_string (d, "info.linux.driver", 
"mac80211_hwsim");
+   parent_dev = hal_device_store_find (hald_get_gdl (), 
"/org/freedesktop/Hal/devices/computer");
+   hal_device_property_set_string (parent_dev, 
"info.linux.driver", "mac80211");
+   }
 
hal_device_property_set_string (d, "info.category", "net");
hal_device_add_capability (d, "net");
 
-   hal_device_property_set_string (d, "net.originating_device", 
hal_device_get_udi (parent_dev));
-
ifname = hal_util_get_last_element (sysfs_path);
hal_device_property_set_string (d, "net.interface", ifname);
 
@@ -530,7 +532,7 @@ net_add (const gchar *sysfs_path, const gchar *device_file, 
HalDevice *parent_de
media_type = hal_device_property_get_int (d, "net.arp_proto_hw_id");
if (media_type == ARPHRD_ETHER) {
const char *addr;
-   const char *parent_subsys;
+   const char *parent_subsys = 0;
char bridge_path[HAL_PATH_MAX];
char wireless_path[HAL_PATH_MAX];
char wiphy_path[HAL_PATH_MAX];
@@ -557,7 +559,8 @@ net_add (const gchar *sysfs_path, const gchar *device_file, 
HalDevice *parent_de
snprintf (wireless_path, HAL_PATH_MAX, "%s/wireless", 
sysfs_path);
/* wireless dscape stack e.g. from rt2500pci driver*/
snprintf (wiphy_path, HAL_PATH_MAX, "%s/wiphy", sysfs_path);
-   parent_subsys = hal_device_property_get_string (parent_dev, 
"info.subsystem");
+   if (parent_dev)
+   parent_subsys = hal_device_property_get_string 
(parent_dev, "info.subsystem");
 
if (parent_subsys && strcmp(parent_subsys, "bluetooth") == 0) {
hal_device_property_set_string (d, "info.product", 
"Bluetooth Interface");
-- 
1.6.0.2.GIT

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

Re: NetworkManager and mac80211_hwsim

2009-02-16 Thread Daniel Wagner 
On Mon, Feb 16, 2009 at 05:04:44PM +0100, Johannes Berg wrote:
> On Mon, 2009-02-16 at 17:00 +0100, Daniel Wagner wrote:
> 
> > hotplug_event_begin_add_dev (..., parent_dev = NULL, ...)
> >   net_add(..., parent_dev = NULL, ...)
> >   {
> > if (parent_dev == NULL)
> > goto error;
> >   }
> > 
> > Before I go deeper into that thing, does someone has
> > an idea what could go wrong here with mac80211_hwsim?
> 
> hwsim phys have no parents in sysfs since they're virtual.

Do you propose to patch hald to handle this situation then?

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

NetworkManager and mac80211_hwsim

2009-02-16 Thread Daniel Wagner 
Hi

I'd like to setup a simple test scenario with mac80211_hwsim in
order to check some corner cases in the scanning behaviour
in NetworkManager. Though the problem is that NM doesn't see
the mac8011_hwsim devices. I found out that the problem is
that hald won't notifiy on dbus there is a new wireless device
available. After a bit debugging I can tell that the problem is
that there isn't a parent device available:

hal/hald/device.c:

hotplug_event_begin_add_dev (..., parent_dev = NULL, ...)
  net_add(..., parent_dev = NULL, ...)
  {
if (parent_dev == NULL)
goto error;
  }

Before I go deeper into that thing, does someone has
an idea what could go wrong here with mac80211_hwsim?

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

Re: [RFC] Make scan mode configurable

2009-02-10 Thread Daniel Wagner 
On Tue, Feb 10, 2009 at 11:24:23AM -0500, Dan Williams wrote:
> On Tue, 2009-02-10 at 08:50 +0100, Daniel Wagner wrote:
> > This adds support for continuously scanning. Also it alows to specify
> > the scan inteval and the pruning time at runtime.
> 
> Ideally, nobody should have to touch internal scan details.  

Yeah, I think we all agree on that.

> The reason
> people keep wanting to is a combination of issues in drivers, the
> supplicant, and NetworkManager itself.
> 
> * kernel drivers
> - Many drivers can't do specific-SSID scans (airo and out-of-tree
>   drivers mainly)
> - Drivers don't always honor specific-SSID scans; with iwlwifi and
>   hardware scanning, errors aren't returned to userspace so NM
>   doesn't know when requested scans can't be performed.
> - Not all drivers report last beacon times
> 
> * WEXT
> - Cannot adequately report errors from most operations

I expect that Johannes's scan API patches for cfg80211 should soon be 
available (in wireless-testing). I guess it isn't worth spending time 
on WEXT.

> * wpa_supplicant
> - D-Bus interface can't take specific SSIDs to scan
> 
> * NetworkManager
> - Doesn't have a good mechanism to report when users want better
>   scan information
> - Scan backoff algorithm needs to be optimized
> - There could be bugs in the pruning algorithm
> 

Thanks for this list. As I see there is a lot of things to work on :)

Could you tell me what you have in mind on how NM can report better scan
information?

> Obviously, the main problem is that not every AP is reported in each
> scan, which is partially the fault of the drivers for not supporting
> specific-SSID and active scans, and partly just wireless being
> unreliable by definition.  This is what kills continuous scanning which
> throws away the AP list each scan.  Sometimes your AP will be there,
> sometimes it won't, depending on whether somebody turned on a microwave
> during the scan.  You really do need some meta-tracking of scan results
> across scans.

Indeed some sort of filtering is needed. 

> There's a few things we can do, patches for them gratefully accepted:
> 
> - Scan more often when not associated to anything, which helps your case

As I understand this will help when we don't have a connection so far. The 
other case (disappearing AP) could be solved when we get some information
from the drivers that we missed beacons. And then we could start again
we more agressive scanning. 

> - If the scan list changes substantially (in a car, on the train, etc)
> across a few scans, make the prune interval smaller.  ie, if AP turnover
> is > 50% in two successive scans, be more aggressive about dropping
> older APs.  This would work much better in combination with 

Yes that sounds like the logical next thing to get working.

> - 0.6 had a mechanism for the applet to notify NetworkManager that the
> user was actively interested in the network status; each time the menu
> was pulled down, the applet would tell NM, and NM would assume the user
> was interested in the network topology, and decrease the scan interval,
> or perform an immediate scan if one hadn't been done recently.  Ideally
> this would take the form of a new signal of the
> org.freedesktop.NetworkManagerSettings interface for "UserActivity" (or
> some better name) that NM would listen for.

Well, I'm currently not really interested in the applet but who knows, if
the fruits are hanging low I can work on that too :)

> Any of these sound interesting to you?

Sure, I think I will start with NM and then dig deeper. So I start with
looking at the backup algorithm and the pruning.

thanks,
daniel

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

Re: [RFC] Make scan mode configurable

2009-02-10 Thread Daniel Wagner 
On Tue, Feb 10, 2009 at 02:40:01PM +0200, Tambet Ingo wrote:
> On Tue, Feb 10, 2009 at 14:20, Daniel Wagner  wrote:
> > On Tue, Feb 10, 2009 at 01:12:02PM +0200, Tambet Ingo wrote:
> >> What would call the API you added (other than your test program)?
> >
> > Good question. I assumed this could be an option in the nm-applet.
> 
> The problem is there's no place to put it there. There's no per-device
> configuration location anywhere, all the configuration is NMConnection
> specific.

Okay, I didn't realize this.

> >> Who would want/need to use that UI?
> >
> > I can just write about the problem I wanted to fix. The time needed
> > to recognize there is a new AP or an AP disappeared was just too long.
> > Of course if you don't have a "fast" changing network setup this is not
> > really problem. This is all about moving around with your laptop/device and
> > if it takes 120 seconds to see there is a new AP and 360 seconds to
> > remove the AP from the list is just a bit too long IHMO.
> 
> Can you use wireless when you move that fast? :) Surely you can't stay
> connected to any of the APs?

My use case is not about to stay connected when I move around. This might
be the next thing I'd like to look at. It is as you say "I want my wireless 
APs appear/disappear faster". Hopping from one hot spot to the next one 
(read: open AP) :)

> > If I didn't get it completely wrong, connman uses continuously
> > scanning to overcome this problem.
> 
> That's exactly what I meant by being device specific. Connman only
> cares about a few selected wireless cards that support passive
> scanning, NM needs to also work on cards where a scan request takes
> noticeable amount of time (when no other IP traffic could be sent).

I was not aware of this problem, though I should have. Argh! 

> >> Is it wireless device specific?
> >
> > The patch allows to set the scan interval for each device separately.
> > Basically the patch just changes default behavior in NM. The
> > scan is still triggered through the wpa_supplicant interface.
> >
> >> If it's card specific, then we can do the right thing in the NM
> >> without asking users to try random options if something doesn't feel
> >> right.
> >
> > No, it is not card specific. Okay I think you are right about
> 
> Sounds like it still is.

Hmm, I think I don't understand you here. What do you mean with card specific?
The thing you explaned above (passive/active scan)? I was talking about
dependencies on hardware specific HW interface (madwifi vs. wext vs. cfg80211, 
etc.)

> > offering users too many knobs to play with. How do you propose
> > to "fix" my use case?
> 
> I don't know much about wireless drivers, but maybe a new capability
> for drivers, IW_SCAN_CAPA_SOMETHING? 

As I said I'm not sure where the scanning policy belongs to.

> Dan or Helmut will have a better
> answer. But having UI for something like "I want my wireless APs
> appear/disappear faster" is certainly not a solution, everybody wants
> that.

Clearly, this is what we should aim for :)

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

Re: [RFC] Make scan mode configurable

2009-02-10 Thread Daniel Wagner 
On Tue, Feb 10, 2009 at 01:12:02PM +0200, Tambet Ingo wrote:
> On Tue, Feb 10, 2009 at 12:45, Daniel Wagner  wrote:
> > BTW, I have small python/qt application here[1] which allows
> > you to play around with it.
> 
> What would call the API you added (other than your test program)?

Good question. I assumed this could be an option in the nm-applet. 

> Who would want/need to use that UI? 

I can just write about the problem I wanted to fix. The time needed 
to recognize there is a new AP or an AP disappeared was just too long.
Of course if you don't have a "fast" changing network setup this is not
really problem. This is all about moving around with your laptop/device and 
if it takes 120 seconds to see there is a new AP and 360 seconds to 
remove the AP from the list is just a bit too long IHMO.

If I didn't get it completely wrong, connman uses continuously 
scanning to overcome this problem.

> Is it wireless device specific?

The patch allows to set the scan interval for each device separately.
Basically the patch just changes default behavior in NM. The
scan is still triggered through the wpa_supplicant interface.

> If it's card specific, then we can do the right thing in the NM
> without asking users to try random options if something doesn't feel
> right.

No, it is not card specific. Okay I think you are right about
offering users too many knobs to play with. How do you propose
to "fix" my use case?

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

Re: [RFC] Make scan mode configurable

2009-02-10 Thread Daniel Wagner 
BTW, I have small python/qt application here[1] which allows
you to play around with it.

daniel

[1] http://www.monom.org/~wagi/nmctrl.tar.bz
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[RFC] Make scan mode configurable

2009-02-09 Thread Daniel Wagner 
This adds support for continuously scanning. Also it alows to specify
the scan inteval and the pruning time at runtime.

Signed-off-by: Daniel Wagner 
---
The idea behind this patch is to be able to recognize AP a bit faster then
the standard algorithm in NM. I'm not completely sure where this continuously
scaning code should go. Propably all that should be handled by wpa_supplicant?

If you don't like this patch, no problem with me. In case you like it I guess
some more work is needed. For example I really don't know how you get those
interesting tab-space indentions. :) 

 include/NetworkManager.h |8 ++
 introspection/nm-device-wifi.xml |   16 +++
 libnm-glib/nm-device-wifi.c  |  203 ++
 libnm-glib/nm-device-wifi.h  |   12 +++
 src/nm-device-wifi.c |  164 ++-
 src/nm-device-wifi.h |3 +
 6 files changed, 380 insertions(+), 26 deletions(-)

diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index d61a89c..380d896 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -141,6 +141,14 @@ typedef enum {
NM_802_11_MODE_INFRA
 } NM80211Mode;
 
+/*
+ * 802.11 Scan mode behaviour
+ *
+ */
+typedef enum {
+   NM_802_11_SCAN_MODE_DEFAULT = 0,
+   NM_802_11_SCAN_MODE_CONTINUOUSLY, 
+} NM80211ScanMode;
 
 /*
  * Device states
diff --git a/introspection/nm-device-wifi.xml b/introspection/nm-device-wifi.xml
index 21ace0a..55d4135 100644
--- a/introspection/nm-device-wifi.xml
+++ b/introspection/nm-device-wifi.xml
@@ -41,6 +41,22 @@
   
 
 
+
+  
+   Scan mode.
+  
+
+
+  
+   Scan interval value in seconds.
+  
+
+
+  
+   Scan prune value in seconds.
+  
+
+
 
 
 
diff --git a/libnm-glib/nm-device-wifi.c b/libnm-glib/nm-device-wifi.c
index 1729c8a..dde76d1 100644
--- a/libnm-glib/nm-device-wifi.c
+++ b/libnm-glib/nm-device-wifi.c
@@ -51,6 +51,9 @@ typedef struct {
gboolean null_active_ap;
guint32 wireless_caps;
GPtrArray *aps;
+   guint scan_mode;
+   guint scan_interval;  /* seconds */
+   guint scan_prune; /* seconds */
 
gboolean wireless_enabled;
 } NMDeviceWifiPrivate;
@@ -62,6 +65,9 @@ enum {
PROP_BITRATE,
PROP_ACTIVE_ACCESS_POINT,
PROP_WIRELESS_CAPABILITIES,
+   PROP_WIRELESS_SCAN_MODE,
+   PROP_WIRELESS_SCAN_INTERVAL,
+   PROP_WIRELESS_SCAN_PRUNE,
 
LAST_PROP
 };
@@ -71,6 +77,9 @@ enum {
 #define DBUS_PROP_BITRATE "Bitrate"
 #define DBUS_PROP_ACTIVE_ACCESS_POINT "ActiveAccessPoint"
 #define DBUS_PROP_WIRELESS_CAPABILITIES "WirelessCapabilities"
+#define DBUS_PROP_WIRELESS_SCAN_MODE "WirelessScanMode"
+#define DBUS_PROP_WIRELESS_SCAN_INTERVAL "WirelessScanInterval"
+#define DBUS_PROP_WIRELESS_SCAN_PRUNE "WirelessScanPrune"
 
 enum {
ACCESS_POINT_ADDED,
@@ -218,6 +227,138 @@ nm_device_wifi_get_capabilities (NMDeviceWifi *device)
 }
 
 /**
+ * nm_device_wifi_get_scan_mode:
+ * @device: a #NMDeviceWifi
+ *
+ * Gets the wireless scan mode of the #NMDeviceWifi.
+ *
+ * Returns: the wireless scan mode
+ **/
+guint32
+nm_device_wifi_get_scan_mode (NMDeviceWifi *device)
+{
+   NMDeviceWifiPrivate *priv;
+
+   g_return_val_if_fail (NM_IS_DEVICE_WIFI (device), 0);
+
+   priv = NM_DEVICE_WIFI_GET_PRIVATE (device);
+   priv->scan_mode = _nm_object_get_uint_property (NM_OBJECT (device),
+   
NM_DBUS_INTERFACE_DEVICE_WIRELESS,
+   
DBUS_PROP_WIRELESS_SCAN_MODE);
+   return priv->scan_mode;
+}
+
+/**
+ * nm_device_wifi_get_scan_interval:
+ * @device: a #NMDeviceWifi
+ *
+ * Gets the wireless scan interval of the #NMDeviceWifi.
+ *
+ * Returns: the wireless scan interval
+ **/
+guint32
+nm_device_wifi_get_scan_interval (NMDeviceWifi *device)
+{
+   NMDeviceWifiPrivate *priv;
+
+   g_return_val_if_fail (NM_IS_DEVICE_WIFI (device), 0);
+
+   priv = NM_DEVICE_WIFI_GET_PRIVATE (device);
+   priv->scan_interval = _nm_object_get_uint_property (NM_OBJECT (device),
+   
NM_DBUS_INTERFACE_DEVICE_WIRELESS,
+   
DBUS_PROP_WIRELESS_SCAN_INTERVAL);
+   return priv->scan_interval;
+}
+
+/**
+ * nm_device_wifi_get_scan_prune:
+ * @device: a #NMDeviceWifi
+ *
+ * Gets the wireless scan prune of the #NMDeviceWifi.
+ *
+ * Returns: the wireless scan prune
+ **/
+guint32
+nm_device_wifi_get_scan_prune (NMDeviceWifi *device)
+{
+   NMDeviceWifiPrivat