[PATCH] agent: fix a double free in agent message handling

2014-05-14 Thread Hannu Mallat
It could happen that cleaning up the pending message in
agent_receive_message() would as a side effect clear the last
reference to the service via driver context unref function pointer.
Service cleanup would then call connman_agent_cancel(), which would
try to clean up the pending message for the second time as the pending
pointer was still non-NULL.

Fixed by decoupling the pointer to the pending request from the agent
structure before calling agent_request_free().
---
 src/agent.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/src/agent.c b/src/agent.c
index b9b8dd9..37cf524 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -112,6 +112,17 @@ static void agent_request_free(struct 
connman_agent_request *request)
g_free(request);
 }
 
+static void agent_finalize_pending(struct connman_agent *agent,
+   DBusMessage *reply)
+{
+   struct connman_agent_request *pending = agent-pending;
+   if (pending) {
+   agent-pending = NULL;
+   pending-callback(reply, pending-user_data);
+   agent_request_free(pending);
+   }
+}
+
 static void agent_receive_message(DBusPendingCall *call, void *user_data);
 
 static int agent_send_next_request(struct connman_agent *agent)
@@ -146,9 +157,7 @@ static int agent_send_next_request(struct connman_agent 
*agent)
return 0;
 
 fail:
-   agent-pending-callback(NULL, agent-pending-user_data);
-   agent_request_free(agent-pending);
-   agent-pending = NULL;
+   agent_finalize_pending(agent, NULL);
return -ESRCH;
 }
 
@@ -191,12 +200,9 @@ static void agent_receive_message(DBusPendingCall *call, 
void *user_data)
send_cancel_request(agent, agent-pending);
}
 
-   agent-pending-callback(reply, agent-pending-user_data);
+   agent_finalize_pending(agent, reply);
dbus_message_unref(reply);
 
-   agent_request_free(agent-pending);
-   agent-pending = NULL;
-
err = agent_send_next_request(agent);
if (err  0  err != -EBUSY)
DBG(send next request failed (%s/%d), strerror(-err), -err);
@@ -456,9 +462,7 @@ static void cancel_all_requests(struct connman_agent *agent)
if (agent-pending-call)
send_cancel_request(agent, agent-pending);
 
-   agent-pending-callback(NULL, agent-pending-user_data);
-   agent_request_free(agent-pending);
-   agent-pending = NULL;
+   agent_finalize_pending(agent, NULL);
}
 
for (list = agent-queue; list; list = list-next) {
@@ -521,12 +525,7 @@ void connman_agent_cancel(void *user_context)
if (agent-pending-call)
send_cancel_request(agent, agent-pending);
 
-   agent-pending-callback(NULL,
-   agent-pending-user_data);
-
-   agent_request_free(agent-pending);
-
-   agent-pending = NULL;
+   agent_finalize_pending(agent, NULL);
 
err = agent_send_next_request(agent);
if (err  0  err != -EBUSY)
-- 
1.8.5.3

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH] agent: check for NULL parameter

2014-05-14 Thread Hannu Mallat
Check for reply parameter being NULL before using it.
---
 src/agent-connman.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/agent-connman.c b/src/agent-connman.c
index 203edf0..ab538f3 100644
--- a/src/agent-connman.c
+++ b/src/agent-connman.c
@@ -354,6 +354,9 @@ static void request_input_login_reply(DBusMessage *reply, 
void *user_data)
char *key;
DBusMessageIter iter, dict;
 
+   if (!reply)
+   goto out;
+
if (dbus_message_get_type(reply) == DBUS_MESSAGE_TYPE_ERROR) {
error = dbus_message_get_error_name(reply);
goto done;
@@ -401,6 +404,8 @@ done:
username, password,
FALSE, NULL, error,
username_password_reply-user_data);
+
+out:
g_free(username_password_reply);
 }
 
-- 
1.8.5.3

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH] network: Properly remove addresses When DHCPv4 lease is lost

2014-05-14 Thread Patrik Flykt
As addresses were not properly removed, the D-Bus API showed IP
addresses even if the interface addresses and routing is removed
when the DHCP lease has been lost. Also ensure that the network
is no longer associating, should the lease have been lost at
startup.

As the DHCP will nowadays continue trying after a lease is lost,
don't make the upper layers stop the DHCP procedure. Add better
logging so that lease acquired and lost can be properly noticed.
---
 src/network.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/network.c b/src/network.c
index ce6fa85..39ab8e9 100644
--- a/src/network.c
+++ b/src/network.c
@@ -157,6 +157,8 @@ static void dhcp_success(struct connman_network *network)
 
network-connecting = false;
 
+   DBG(lease acquired for ipconfig %p, ipconfig_ipv4);
+
ipconfig_ipv4 = __connman_service_get_ip4config(service);
err = __connman_ipconfig_address_add(ipconfig_ipv4);
if (err  0)
@@ -175,14 +177,27 @@ err:
 
 static void dhcp_failure(struct connman_network *network)
 {
-   __connman_dhcp_stop(network);
+   struct connman_service *service;
+   struct connman_ipconfig *ipconfig_ipv4;
+
+   service = connman_service_lookup_from_network(network);
+   if (!service)
+   return;
+
+   connman_network_set_associating(network, false);
+   network-connecting = false;
+
+   ipconfig_ipv4 = __connman_service_get_ip4config(service);
+
+   DBG(lease lost for ipconfig %p, ipconfig_ipv4);
+
+   __connman_ipconfig_address_remove(ipconfig_ipv4);
+   __connman_ipconfig_gateway_remove(ipconfig_ipv4);
 }
 
 static void dhcp_callback(struct connman_network *network,
bool success, gpointer data)
 {
-   DBG(success %d, success);
-
if (success)
dhcp_success(network);
else
-- 
1.9.1

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH 2/2] test: Arg parsing for p2p-on-supplication

2014-05-14 Thread Tomasz Bursztyka

Hi Eduardo,

Minor issue:


@@ -100,37 +105,33 @@ class Wpa_s:
  bus.add_signal_receiver(self.__InterfaceRemoved, path=WPA_PATH,
  signal_name='InterfaceRemoved')
  self.__reset()
+
+self.debug = False


unnecessary since it's done below already.


+
+self.bus = bus
+
  self.debug = False
  



Rest is fine.

Thanks,

Tomasz

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH 2/2] test: Arg parsing for p2p-on-supplication

2014-05-14 Thread Eduardo Abinader
Hi Tomasz,
On Wed, May 14, 2014 at 2:54 AM, Tomasz Bursztyka
tomasz.burszt...@linux.intel.com wrote:
 Hi Eduardo,

 Minor issue:

 @@ -100,37 +105,33 @@ class Wpa_s:
   bus.add_signal_receiver(self.__InterfaceRemoved, path=WPA_PATH,
   signal_name='InterfaceRemoved')
   self.__reset()
 +
 +self.debug = False


 unnecessary since it's done below already.

Should I resend the patch or send a new one fixing this issue?


 +
 +self.bus = bus
 +
   self.debug = False




 Rest is fine.

 Thanks,

Thanks.


 Tomasz

 ___
 connman mailing list
 connman@connman.net
 https://lists.connman.net/mailman/listinfo/connman
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH 2/2] test: Arg parsing for p2p-on-supplication

2014-05-14 Thread Eduardo Abinader
Argument parsing functionality for commands and options:
- dbus is now wpa_s property
- help is being shown from the command_list built in arg
parse time
- Added enum like class (ArgFields) for future options in arg
parsing
---
 test/p2p-on-supplicant | 174 +++--
 1 file changed, 126 insertions(+), 48 deletions(-)

diff --git a/test/p2p-on-supplicant b/test/p2p-on-supplicant
index 734396e..025bf6e 100755
--- a/test/p2p-on-supplicant
+++ b/test/p2p-on-supplicant
@@ -1,12 +1,13 @@
 #!/usr/bin/python
 
 from os import O_NONBLOCK
-from sys import stdin, stdout, exit, version_info
+from sys import stdin, stdout, exit, version_info, argv
 from fcntl import fcntl, F_GETFL, F_SETFL
 import glib
 import dbus
 import dbus.mainloop.glib
 import gobject
+import argparse
 
 WPA_NAME='fi.w1.wpa_supplicant1'
 WPA_INTF='fi.w1.wpa_supplicant1'
@@ -19,6 +20,10 @@ DBUS_PROPERTIES_INTF = 'org.freedesktop.DBus.Properties'
 
 P2P_GROUP_CAPAB_GROUP_OWNER = 1  0
 
+class ArgFields:
+for i in ('help','metavar'):
+exec('{}={}'.format(i,i))
+
 class InputLine:
 def __init__(self, handler):
 self.line = ''
@@ -91,7 +96,7 @@ def print_tuple(t):
 print 'Element: %s' % e
 
 class Wpa_s:
-def __init__(self, iface_name = None):
+def __init__(self, bus, iface_name, command):
 self.wpa = dbus.Interface(bus.get_object(WPA_NAME, WPA_PATH), WPA_INTF)
 bus.add_signal_receiver(self.__wpa_property_changed, path=WPA_PATH,
 member_keyword='signal')
@@ -100,37 +105,31 @@ class Wpa_s:
 bus.add_signal_receiver(self.__InterfaceRemoved, path=WPA_PATH,
 signal_name='InterfaceRemoved')
 self.__reset()
+
+self.bus = bus
+
 self.debug = False
 
 self.line_in = InputLine(self.__command)
 
-if self.iface_name != None:
-self.create_if(self.iface_name)
+if iface_name:
+try:
+self.create_if([iface_name])
+except:
+print Error creating interface: %s % iface_name
+
+if len(command.strip(' ')):
+self.__command(command)
 
 def help(self, args):
-print 'Commands:'
-print 'quit'
-print 'enable_debug'
-print 'disable_debug'
-print 'create_if iface_name'
-print 'get_if iface_name'
-print 'del_if'
-print 'scan'
-print 'p2p_find'
-print 'p2p_stop_find'
-print 'p2p_flush'
-print 'p2p_group_add'
-print 'p2p_group_remove'
-print 'p2p_group'
-print 'p2p_peers'
-print 'p2p_peer p2p device name'
-print 'p2p_connect p2p device name'
-print 'p2p_disconnect p2p device name'
-print 'p2p_serv_disc_req'
-print 'p2p_serv_disc_cancel_req identifier'
-print 'p2p_service_add service type version/query 
service/response'
-print 'p2p_service_del service type version/query [service]'
-print 'p2p_service_flush'
+list = self.command_list.keys()
+list.sort()
+for key in list:
+help = ''
+if (self.command_list[key].has_key(ArgFields.help)):
+help = self.command_list[key][ArgFields.help]
+
+print %s\t%s % (key.rjust(25), help.ljust(50))
 
 def __command(self, cmd_line):
 cmd = cmd_line.split(' ')
@@ -172,7 +171,7 @@ class Wpa_s:
 def __DeviceFound(self, object_path):
 self.peers[object_path] = None
 
-peer = bus.get_object(WPA_INTF, object_path)
+peer = self.bus.get_object(WPA_INTF, object_path)
 peer_if = dbus.Interface(peer, DBUS_PROPERTIES_INTF)
 
 self.peers[object_path] = peer_if.GetAll(WPA_PEER_INTF)
@@ -201,35 +200,36 @@ class Wpa_s:
 
 def __GroupStarted(self, properties):
 self.group_obj = properties['group_object']
-bus.add_signal_receiver(self.__PeerJoined,
+self.bus.add_signal_receiver(self.__PeerJoined,
 dbus_interface=WPA_GROUP_INTF,
 path=self.group_obj,
 signal_name='PeerJoined')
-bus.add_signal_receiver(self.__PeerDisconnected,
+self.bus.add_signal_receiver(self.__PeerDisconnected,
 dbus_interface=WPA_GROUP_INTF,
 path=self.group_obj,
 signal_name='PeerDisconnected')
 
 self.group_iface_path = properties['interface_object']
-self.group_if = dbus.Interface(bus.get_object(WPA_INTF,
+self.group_if = dbus.Interface(self.bus.get_object(WPA_INTF,
self.group_iface_path),
WPA_P2P_INTF)
-bus.add_signal_receiver(self.__group_if_property_changed,
+

[PATCH 1/2] test: Minor typos removal in p2p-on-supplicant

2014-05-14 Thread Eduardo Abinader
Removed minor typo issues in p2p-on-supplicant.
---
 test/p2p-on-supplicant | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/p2p-on-supplicant b/test/p2p-on-supplicant
index e845c88..734396e 100755
--- a/test/p2p-on-supplicant
+++ b/test/p2p-on-supplicant
@@ -185,7 +185,7 @@ class Wpa_s:
 print 'Peer %s joined' % object_path
 
 def __PeerDisconnected(self, object_path):
-print 'Peer %s dictonnected' % object_path
+print 'Peer %s disconnected' % object_path
 
 def __group_if_property_changed(*args, **kwargs):
 print 'Group - ',
@@ -299,7 +299,7 @@ class Wpa_s:
 self.debug = True
 
 @checkarg()
-def disable_debug(serf, args):
+def disable_debug(self, args):
 self.debug = False
 
 @checkarg(nb_args=1)
-- 
1.9.1

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH 2/2] test: Arg parsing for p2p-on-supplication

2014-05-14 Thread Patrik Flykt
On Wed, 2014-05-14 at 06:25 -0400, Eduardo Abinader wrote:
 Should I resend the patch or send a new one fixing this issue?

Yes, please. Once you do that, please add a version to the patch message
like so: 'git format-patch --cover-letter --subject-prefix=PATCH
v3 ...'. This way it's much easier to find the whole patch set as they
all dangle from the cover letter and the version number makes it clear
which one is the newest.

We can omit further resends this time if the newest version was sent
today 07:39:34 -0400 (2014-05-14 14:39:34)

Cheers,

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH] agent: check for NULL parameter

2014-05-14 Thread Patrik Flykt
On Wed, 2014-05-14 at 09:22 +0300, Hannu Mallat wrote:
 Check for reply parameter being NULL before using it.

Applied, thanks!

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH v3] rtnl: Don't watch slave interfaces

2014-05-14 Thread Patrik Flykt
On Tue, 2014-05-13 at 10:43 -0700, Justin Maggard wrote:
 If you are using a bond interface, the bond interface and the slave
 interfaces will share the same MAC address.  This can eventually
 cause connman to crash, because several things depend on a unique
 MAC address per interface.

Applied, thanks!

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH] agent: fix a double free in agent message handling

2014-05-14 Thread Patrik Flykt
On Wed, 2014-05-14 at 09:12 +0300, Hannu Mallat wrote:
 It could happen that cleaning up the pending message in
 agent_receive_message() would as a side effect clear the last
 reference to the service via driver context unref function pointer.
 Service cleanup would then call connman_agent_cancel(), which would
 try to clean up the pending message for the second time as the pending
 pointer was still non-NULL.
 
 Fixed by decoupling the pointer to the pending request from the agent
 structure before calling agent_request_free().

Applied, thanks!

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH] network: Properly remove addresses When DHCPv4 lease is lost

2014-05-14 Thread Patrik Flykt
On Wed, 2014-05-14 at 09:35 +0300, Patrik Flykt wrote:
 As addresses were not properly removed, the D-Bus API showed IP
 addresses even if the interface addresses and routing is removed
 when the DHCP lease has been lost. Also ensure that the network
 is no longer associating, should the lease have been lost at
 startup.
 
 As the DHCP will nowadays continue trying after a lease is lost,
 don't make the upper layers stop the DHCP procedure. Add better
 logging so that lease acquired and lost can be properly noticed.

Applied, fixed commit message and checked that ipconfig_ipv4 is non-NULL
before use.

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH 1/2] test: Minor typos removal in p2p-on-supplicant

2014-05-14 Thread Patrik Flykt
On Wed, 2014-05-14 at 07:39 -0400, Eduardo Abinader wrote:
 Removed minor typo issues in p2p-on-supplicant.

Applied, thanks!

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH 2/2] test: Arg parsing for p2p-on-supplication

2014-05-14 Thread Patrik Flykt
On Wed, 2014-05-14 at 07:39 -0400, Eduardo Abinader wrote:
 Argument parsing functionality for commands and options:
   - dbus is now wpa_s property
   - help is being shown from the command_list built in arg
   parse time
   - Added enum like class (ArgFields) for future options in arg
   parsing

Applied, thanks!

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH 1/3] gsupplicant: Fix an emptyness test on an array

2014-05-14 Thread Tomasz Bursztyka
Reported by Daniel Wagner daniel.wag...@bmw-carit.de
---
 gsupplicant/supplicant.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 8a16663..b483f9b 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2411,10 +2411,12 @@ static void signal_wps_event(const char *path, 
DBusMessageIter *iter)
 
 static void create_peer_identifier(GSupplicantPeer *peer)
 {
+   const unsigned char test[6] = {};
+
if (!peer)
return;
 
-   if (!peer-device_address) {
+   if (!memcmp(peer-device_address, test, 6)) {
peer-identifier = g_strdup(peer-name);
return;
}
-- 
1.8.3.2

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH 3/3] wifi: Check the returned code when registering the P2P technology driver

2014-05-14 Thread Tomasz Bursztyka
Reported by Daniel Wagner daniel.wag...@bmw-carit.de
---
 plugins/wifi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/plugins/wifi.c b/plugins/wifi.c
index 7c412ef..988ca1a 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1885,8 +1885,11 @@ static void p2p_support(GSupplicantInterface *interface)
 {
DBG();
 
-   if (g_supplicant_interface_has_p2p(interface))
-   connman_technology_driver_register(p2p_tech_driver);
+   if (!g_supplicant_interface_has_p2p(interface))
+   return;
+
+   if (connman_technology_driver_register(p2p_tech_driver) == 0)
+   DBG(Could not register P2P technology driver);
 }
 
 static void scan_started(GSupplicantInterface *interface)
-- 
1.8.3.2

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH 2/3] technology: Fix a false positive null dereference

2014-05-14 Thread Tomasz Bursztyka
P2P technology cannot exist without wifi technology, so if P2P is
present, wifi is present as well. Thus what coverity thinks is a null
dereference is a false positive here.

Reported by Daniel Wagner daniel.wag...@bmw-carit.de
---
 src/technology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/technology.c b/src/technology.c
index a917a6c..d80d9e6 100644
--- a/src/technology.c
+++ b/src/technology.c
@@ -708,7 +708,7 @@ static int technology_enable(struct connman_technology 
*technology)
struct connman_technology *wifi;
 
wifi = technology_find(CONNMAN_SERVICE_TYPE_WIFI);
-   if (wifi-enabled)
+   if (wifi  wifi-enabled)
return technology_enabled(technology);
return 0;
}
-- 
1.8.3.2

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Unreachable favorite network

2014-05-14 Thread Julien Massot
Hi ConnMan developers,

My users are requesting stronger than before to be able to remove
unreachable favorites services.

At the moment it's not possible with ConnMan API.

I understand that returning unreachable networks is quiet confusing,
but I think their request is legitimate.

Often they think they remove all the favorite networks in the UI list,
and they don't understand that some networks are still stored.

Sometimes it results in unwanted wifi passphrase leaks,
or connection to a no longer wanted network.

The naive way of thinking is to return these networks with
GetServices method of net.connman.Manager interface.

These services may required a new unreachable state.

Does someone already think about a possible implementation for this use
case ?

Best regards,
Julien
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: Unreachable favorite network

2014-05-14 Thread Tomasz Bursztyka

Hi Julien,


Often they think they remove all the favorite networks in the UI list,
and they don't understand that some networks are still stored.


What do they want to do? Selectively removing some known networks, or 
removing all known ones?

If it's the later, a small script could just do that for them.


Sometimes it results in unwanted wifi passphrase leaks,


How come? The passphrase are stored in a restricted directory in 
/var/lib/connman

If someone/something can read there, the machine is corrupted anyway.


or connection to a no longer wanted network.


Well they can fix that then at that point, via un-favoriting the network 
at that point. ;)



The naive way of thinking is to return these networks with
GetServices method of net.connman.Manager interface.


Imagine the mess: you might have 20 networks available + how many 
unreachable ones?

It's even more confusing than the current situation, as you noticed already.


These services may required a new unreachable state.

Does someone already think about a possible implementation for this use
case ?


This has been discussed already, and yet nothing proper has been specified.

Something like a new Manager method, to get the unreachable known networks,
with a possibility to remove them. A StoredService object or kind of, 
with only readable

properties and one method Remove().

It's not like it would make the UI very nice anyway, that's the main 
reason I guess this

issue hasn't been resolved.

Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [PATCH 0/3 v2] Various fixes around P2P

2014-05-14 Thread Patrik Flykt
On Wed, 2014-05-14 at 15:41 +0300, Tomasz Bursztyka wrote:
 My first version of the patchset was made on top of up-coming patches... 

Applied all three patches, thanks!

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: [RFC 1/3] wifi: Don't fetch interface name from device structure

2014-05-14 Thread Patrik Flykt
On Tue, 2014-05-06 at 12:41 +0300, Patrik Flykt wrote:
 Update the code to use connman_inet_ifname() when fetching the
 interface name. This allows the interface name to be removed from
 the device structure, as the interface name is not requested
 from the device structure elsewhere.

Commit messge updated and patch applied. I'll leave out patch 2/3 to
wait for a possible device-interface cleanup that will properly track
interface name changes.

Patrik

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: Unreachable favorite network

2014-05-14 Thread Patrik Flykt

Hi,

On Wed, 2014-05-14 at 15:27 +0200, Julien Massot wrote:
 I understand that returning unreachable networks is quiet confusing,
 but I think their request is legitimate.
 
 Often they think they remove all the favorite networks in the UI list,
 and they don't understand that some networks are still stored.
 
 Sometimes it results in unwanted wifi passphrase leaks,
 or connection to a no longer wanted network.
 
 The naive way of thinking is to return these networks with
 GetServices method of net.connman.Manager interface.
 
 These services may required a new unreachable state.

I think the main idea floated a long time ago with showing services not
present should be rewarded an interface of their own, very similar to
net.connman.Service but without the Connect, Disconnect and
Move{Before,After} method calls. One should be then able to Remove the
service and set/unset its properties. A service can only exist in either
net.connman.Service or net.connman.Stored (or something), but not both.
Signalling for this transition would also be needed.

On the downside this kind of API will eat quite a lot of memory, perhaps
there is a possibility of creating the relevant data structures on the
fly only when needed?

 Does someone already think about a possible implementation for this
 use case ?

So far nobody I know of has shown any interest in implementing this.

Cheers,

Patrik



___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: Unreachable favorite network

2014-05-14 Thread Julien Massot
Hi Tomasz,


On Wed, May 14, 2014 at 3:46 PM, Tomasz Bursztyka 
tomasz.burszt...@linux.intel.com wrote:

 Hi Julien,


  Often they think they remove all the favorite networks in the UI list,
 and they don't understand that some networks are still stored.


 What do they want to do? Selectively removing some known networks, or
 removing all known ones?
 If it's the later, a small script could just do that for them.

Both could be great.



  Sometimes it results in unwanted wifi passphrase leaks,


 How come? The passphrase are stored in a restricted directory in
 /var/lib/connman
 If someone/something can read there, the machine is corrupted anyway.


I was not clear here, when giving the device to someone else we need a way
to be sure networks are deleted,
Or often they give the device without removing all the networks.

Of course it's only possible with the root account (which is not disabled
on device of my company).

I saw a lot of passphrases since the begining :)




  or connection to a no longer wanted network.


 Well they can fix that then at that point, via un-favoriting the network
 at that point. ;)

Yes but If we can avoid that, it could be nice, my devices have no screen,
every thing concerning configuration is complicated.
(Plug ethernet, go on the configuration web page with another computer,
un-favorite the network and connect to the new one)



  The naive way of thinking is to return these networks with
 GetServices method of net.connman.Manager interface.


 Imagine the mess: you might have 20 networks available + how many
 unreachable ones?
 It's even more confusing than the current situation, as you noticed
 already.


  These services may required a new unreachable state.

 Does someone already think about a possible implementation for this use
 case ?


 This has been discussed already, and yet nothing proper has been specified.

 Something like a new Manager method, to get the unreachable known networks,
 with a possibility to remove them. A StoredService object or kind of,
 with only readable
 properties and one method Remove().

 It's not like it would make the UI very nice anyway, that's the main
 reason I guess this
 issue hasn't been resolved.

Yes I know, it's why I haven't do anything at the moment.


 Tomasz
 ___
 connman mailing list
 connman@connman.net
 https://lists.connman.net/mailman/listinfo/connman



Thanks,
Julien
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: Unreachable favorite network

2014-05-14 Thread Julien Massot
Hi Patrick,


On Wed, May 14, 2014 at 4:02 PM, Patrik Flykt
patrik.fl...@linux.intel.comwrote:


 Hi,

 On Wed, 2014-05-14 at 15:27 +0200, Julien Massot wrote:
  I understand that returning unreachable networks is quiet confusing,
  but I think their request is legitimate.
 
  Often they think they remove all the favorite networks in the UI list,
  and they don't understand that some networks are still stored.
 
  Sometimes it results in unwanted wifi passphrase leaks,
  or connection to a no longer wanted network.
 
  The naive way of thinking is to return these networks with
  GetServices method of net.connman.Manager interface.
 
  These services may required a new unreachable state.

 I think the main idea floated a long time ago with showing services not
 present should be rewarded an interface of their own, very similar to
 net.connman.Service but without the Connect, Disconnect and
 Move{Before,After} method calls. One should be then able to Remove the
 service and set/unset its properties. A service can only exist in either
 net.connman.Service or net.connman.Stored (or something), but not both.
 Signalling for this transition would also be needed.

 Does the ServicesChanged signal of Manager interface already do the Job ?
If the service is added it should be no longer returned by
the net.connman.Stored interface.



 On the downside this kind of API will eat quite a lot of memory, perhaps
 there is a possibility of creating the relevant data structures on the
 fly only when needed?

 Seems possible.


  Does someone already think about a possible implementation for this
  use case ?

 So far nobody I know of has shown any interest in implementing this.

 Ok so I will try to handle it, thanks for these tips.



 Cheers,

 Patrik



 ___
 connman mailing list
 connman@connman.net
 https://lists.connman.net/mailman/listinfo/connman



Julien
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: Unreachable favorite network

2014-05-14 Thread Marcel Holtmann
Hi Julien,

 My users are requesting stronger than before to be able to remove
 unreachable favorites services.
 
 At the moment it's not possible with ConnMan API.
 
 I understand that returning unreachable networks is quiet confusing,
 but I think their request is legitimate.
 
 Often they think they remove all the favorite networks in the UI list,
 and they don't understand that some networks are still stored.
 
 Sometimes it results in unwanted wifi passphrase leaks,
 or connection to a no longer wanted network.
 
 The naive way of thinking is to return these networks with
 GetServices method of net.connman.Manager interface.
 
 These services may required a new unreachable state.

and this is a clear NO to such an API. I have seen the Android mess that 
happens in their UI and I do not even want to go anywhere close this.

It needs to be an independent list of object paths with most likely a separate 
interface. If the device is reachable and known they can share an object path 
in that case, but that is about it. We might be getting away with the same 
Service interface and just having Connect etc. return a new and unique error 
message. I do not even have objection if want to change the IP address of a 
service that is not in range. That can be all possible, but you have to 
retrieve that list differently.

This is also a pretty much strong requirement, because otherwise all other 
semantics will break. The current GetServices API is an actual stable API. We 
guarantee that these devices have been found and in range.

Regards

Marcel

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: Unreachable favorite network

2014-05-14 Thread Lorn Potter

On 14 May 2014, at 11:27 pm, Julien Massot jmas...@aldebaran-robotics.com 
wrote:

 Hi ConnMan developers,
 
 My users are requesting stronger than before to be able to remove
 unreachable favorites services.
 
 At the moment it's not possible with ConnMan API.
 
 I understand that returning unreachable networks is quiet confusing,
 but I think their request is legitimate.
 
 Often they think they remove all the favorite networks in the UI list,
 and they don't understand that some networks are still stored.
 
 Sometimes it results in unwanted wifi passphrase leaks,
 or connection to a no longer wanted network.
 
 The naive way of thinking is to return these networks with
 GetServices method of net.connman.Manager interface.
 
 These services may required a new unreachable state.
 
 Does someone already think about a possible implementation for this use
 case ?

Jolla had such a use case, and so we created a patch in our connman repo, which 
exposes those saved/known out of range AP's through dbus. Editing them is only 
possible when in range, except for 'removing' them.

So yes. It is possible.


___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH 2/2] test: Added P2P invite call and signal result

2014-05-14 Thread Eduardo Abinader
Invite discovered P2P peer to join or form a
group.
---
 test/p2p-on-supplicant | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/test/p2p-on-supplicant b/test/p2p-on-supplicant
index 68b4996..3e6f277 100755
--- a/test/p2p-on-supplicant
+++ b/test/p2p-on-supplicant
@@ -198,6 +198,15 @@ class Wpa_s:
 print 'Group running on %s is being removed' % ifname
 self.group_obj = self.group_if = self.group_iface_path = None
 
+def __InvitationResult(self, response):
+print 'Invitation result status: %d ' % response['status']
+
+if response.has_key('bssid'):
+print 'bssid: %s' % response['bssid']
+
+if self.debug:
+print_dict(response)
+
 def __GroupStarted(self, properties):
 self.group_obj = properties['group_object']
 self.bus.add_signal_receiver(self.__PeerJoined,
@@ -225,6 +234,10 @@ class Wpa_s:
 dbus_interface=WPA_P2P_INTF,
 path=self.group_iface_path,
 member_keyword='signal')
+self.bus.add_signal_receiver(self.__InvitationResult,
+dbus_interface=WPA_P2P_INTF,
+path=self.iface_path,
+signal_name='InvitationResult')
 
 if self.debug:
 group = dbus.Interface(self.bus.get_object(WPA_INTF,
@@ -521,6 +534,18 @@ class Wpa_s:
 
 self.p2p.FlushService()
 
+@checkarg(nb_args = 1)
+def p2p_invite(self, args):
+if not self.p2p or not self.group_if:
+return
+
+peer_path = self.__find_peer(args[0], True)
+
+if not peer_path:
+return
+
+self.group_if.Invite({ 'peer' : peer_path})
+
 def build_args(parser):
 parser.add_argument('-d', default=False, action='store_true',
dest='debug', help='enable debug')
@@ -553,6 +578,7 @@ def build_args(parser):
 command['p2p_service_del'] = {ArgFields.help:'service type '
   'version/query [service]'}
 command['p2p_service_flush'] = {}
+command['p2p_invite'] = {ArgFields.help:'p2p device name'}
 
 command_list = command.keys()
 command_list.sort()
-- 
1.9.1

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH 1/2] test: Fix code style in p2p-on-supplicant

2014-05-14 Thread Eduardo Abinader
Just complying to code style.
---
 test/p2p-on-supplicant | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/test/p2p-on-supplicant b/test/p2p-on-supplicant
index 025bf6e..68b4996 100755
--- a/test/p2p-on-supplicant
+++ b/test/p2p-on-supplicant
@@ -21,8 +21,8 @@ DBUS_PROPERTIES_INTF = 'org.freedesktop.DBus.Properties'
 P2P_GROUP_CAPAB_GROUP_OWNER = 1  0
 
 class ArgFields:
-for i in ('help','metavar'):
-exec('{}={}'.format(i,i))
+for field in ('help', 'metavar'):
+exec('{}={}'.format(field, field))
 
 class InputLine:
 def __init__(self, handler):
@@ -522,7 +522,6 @@ class Wpa_s:
 self.p2p.FlushService()
 
 def build_args(parser):
-
 parser.add_argument('-d', default=False, action='store_true',
dest='debug', help='enable debug')
 parser.add_argument('-i', metavar='interface', dest='ifname',
-- 
1.9.1

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


[PATCH 0/2] test: Code style issues and P2P Invite

2014-05-14 Thread Eduardo Abinader
This patchset solves code style minor issues and adds
P2P invite and its signal.

Eduardo Abinader (2):
  test: Fix code style in p2p-on-supplicant
  test: Added P2P invite call and signal result

 test/p2p-on-supplicant | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

-- 
1.9.1

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman