Re: connman and udev network interface renaming

Hi Benoit, > I'm using an udev rule to rename network interfaces on my device. If a > particular interface is plugged before connman is started, the new name > will be used but if it is plugged after, connman will still use the old > name. > > My gut feeling is that it looks racy; Do you think th

Re: [PATCH v3 0/6] OpenVPN improvements

Hi Daniel, On Fri, Dec 17, 2010 at 03:51:59PM +0100, Daniel Wagner wrote: > From: Daniel Wagner > > Hi, > > another round of this series. Looks good now, all patches applied (v4 for patch #6). Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ __

[RFC] Try to manage network interface rename from udev

Check interface name change and store it. Do not merge as is, this breaks ofono's activate_context. --- src/rtnl.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/rtnl.c b/src/rtnl.c index b10d835..06f4ff8 100644 --- a/src/rtnl.c +++ b/src/rtnl.c @@ -462,6 +462,10 @

connman and udev network interface renaming

Hi, I'm using an udev rule to rename network interfaces on my device. If a particular interface is plugged before connman is started, the new name will be used but if it is plugged after, connman will still use the old name. My gut feeling is that it looks racy; Do you think this renaming is just

[PATCH 4/5] Only call connman_device_set_scanning if initiated from connman.

Ignore any scanning happen from supplicant, this usually happen when supplicant start association steps which include scanning, In this step we don't want to update network list or run auto connect after scan since we are already in process of connection. --- include/device.h |2 ++ plugins/wi

[PATCH 3/5] Fix auto_connect race interval

This patch fix the race condition that caused more than one service to start connecting at the same fime by: * Make sure is_connecting always returning the right status of the network and dont allow the small intevel until get the G_SUPPLICANT_STATE_AUTHENTICATING or G_SUPPLICANT_STATE_ASSOCIATING

[PATCH 2/5] Dont start new connection until disassociation complete.

Make sure disconnect is completed before start new connection otherwise we will disconnect the new network when we receive DISCONNECT signal from supplicant. --- --- plugins/wifi.c | 83 +++- 1 files changed, 64 insertions(+), 19 deletions(-)

[PATCH 1/5] Avoid autoconnect from scan.

If we are scanning then don't try to run autoconnect while we are adding network from scan, at the end of scan auto connect will be called. --- src/connman.h |2 ++ src/device.c |5 + src/service.c |8 ++-- 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/src/co

[PATCH v2 2/2] add IPV4LL support in dhcp plugin

This patch is the second version for IPV4LL support in dhcp plugin. --- plugins/dhcp.c | 37 + 1 files changed, 37 insertions(+), 0 deletions(-) diff --git a/plugins/dhcp.c b/plugins/dhcp.c index 73c975d..07fed38 100644 --- a/plugins/dhcp.c +++ b/plugins/dhc

[PATCH v2 1/2] add function to get IPV4LL netmask

this patch is the second version to get netmask when using IPV4LL. --- gdhcp/client.c | 24 gdhcp/gdhcp.h |1 + 2 files changed, 25 insertions(+), 0 deletions(-) diff --git a/gdhcp/client.c b/gdhcp/client.c index 3508b1e..107077a 100644 --- a/gdhcp/client.c +++ b/

Re: [PATCH] WPS support

Hi, On 17/12/10 23:05, ext Marcel Holtmann wrote The agent API looks reasonable to me. How do you plan to handle the PBC case ? and another question is if we are also ready for WPS 2.0 with this. Or are there potential changes coming along. As far as our wlan specialist knows, there s

Re: [PATCH] WPS support

Hi, On 17/12/10 21:26, ext Samuel Ortiz wrote: So before sending any source patch, I would like to agree first on Agent API way of handling WPS input. Patch will follow right away. The agent API looks reasonable to me. How do you plan to handle the PBC case ? PBC is already handled in

[PATCH v4 6/6] OpenVPN: Move foreign_option_ parse code into its own function

From: Daniel Wagner Do not clutter the ov_notify loop with parsing code. --- plugins/openvpn.c | 56 +--- 1 files changed, 31 insertions(+), 25 deletions(-) diff --git a/plugins/openvpn.c b/plugins/openvpn.c index ac36188..f4544fe 100644 --- a/p

[PATCH] WiFi AP list not modified on recieving BSSRemoved signal

Below is a patch for: http://bugs.meego.com/show_bug.cgi?id=11561 When wpa_supplicant indicates that a BSS has been removed by sending a BSSRemoved signal to ConnMan, the WiFi plugin does not remove the respective network and service structures for this BSS. As a result the network is still lis