Re: [PATCH v2] dhcp: Without gateway, the IP is always considered changed when a lease is received

2014-09-16 Thread Patrik Flykt
On Mon, 2014-09-15 at 13:33 +0200, Peter Meerwald wrote:
 From: Peter Meerwald p.meerw...@bct-electronic.com
 
 Connman constantly updates the IP when a lease without gateway is received, 
 e.g.
 connmand[7607]: eth0.42 {del} route 0.0.0.0 gw 0.0.0.0 scope 253 LINK
 connmand[7607]: eth0.42 {add} route 0.0.0.0 gw 0.0.0.0 scope 253 LINK
 connmand[7607]: eth0.42 {del} route 0.0.0.0 gw 0.0.0.0 scope 253 LINK
 connmand[7607]: eth0.42 {add} route 0.0.0.0 gw 0.0.0.0 scope 253 LINK
 
 the problematic condition in dhcp.c/lease_available_cb() is:
 if (!c_address || !c_gateway)
   ip_change = true;
 i.e. no address or gateway configured - IP changed?!
 
 the remaining checks need to be fixed as well, g_strcmp0() already handles
 the case when one or both of the strings is NULL

And applied, thanks!

Cheers,

Patrik


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


Re: timeservers get used up

2014-09-16 Thread Peter Meerwald
Hello Patrik,

  connman builds up available timeservers and keeps them in a list, each 
  timeservers is tried and used in turn
  
  if a timeserver fails (not resolvable, not in sync, kiss-of-death), 
  current timeserver is REMOVED from the list and next one in the list is 
  used
  
  is this the intended behaviour?
 
 So far yes. Every 2h ConnMan wakes up and compares the existing
 timeserver list against a freshly created one. If the first element of
 the current and the fresh timeserver lists differ, the timeserver
 resolution is restarted using the fresh list. This way more preferred
 timeservers are retried every once in a while should they have been
 removed due to connectivity problems. And of course if the connection is
 changed, the timeserver list is reset. See commit
 3b70a3d5a93fb229c2caacf6b2df43dd9ea5b6bd for details.
 
  cycling through the timeserver list is a good idea, but why removing them? 
  after a temporary network outage, a connection may recover but looses all 
  its timeservers
 
 The problem here is to know when to stop and not keep on cycling through
 the list banging on timeservers that are not answering. At the same time
 more preferred ones should be used over the global ones.
 
 Perhaps a modification could be made so that if the list gets exhausted,
 the set of timeservers is retried in something like 5-10 mins?

sounds like a good idea; thanks for the explanation!

thanks, p.

-- 

Peter Meerwald
+43-664-218 (mobile)
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman


Re: timeservers get used up

2014-09-16 Thread Patrik Flykt

Hi,

On Mon, 2014-09-15 at 17:41 +0200, Peter Meerwald wrote:
 Hello Patrik,
 
 connman builds up available timeservers and keeps them in a list, each 
 timeservers is tried and used in turn
 
 if a timeserver fails (not resolvable, not in sync, kiss-of-death), 
 current timeserver is REMOVED from the list and next one in the list is 
 used
 
 is this the intended behaviour?

So far yes. Every 2h ConnMan wakes up and compares the existing
timeserver list against a freshly created one. If the first element of
the current and the fresh timeserver lists differ, the timeserver
resolution is restarted using the fresh list. This way more preferred
timeservers are retried every once in a while should they have been
removed due to connectivity problems. And of course if the connection is
changed, the timeserver list is reset. See commit
3b70a3d5a93fb229c2caacf6b2df43dd9ea5b6bd for details.

 cycling through the timeserver list is a good idea, but why removing them? 
 after a temporary network outage, a connection may recover but looses all 
 its timeservers

The problem here is to know when to stop and not keep on cycling through
the list banging on timeservers that are not answering. At the same time
more preferred ones should be used over the global ones.

Perhaps a modification could be made so that if the list gets exhausted,
the set of timeservers is retried in something like 5-10 mins?


Cheers,

Patrik


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


[RFC/PATCH] gsupplicant: Configure p2p device with WPS PBC method only

2014-09-16 Thread Tomasz Bursztyka
Thus incoming connection will not try to use WPS PIN method. This
enforces connman to support only WPS PBC on incoming connection.
---

Let's wait for wpa_supplicant's patch: 
[PATCH] dbus: Add a device configuration entry to set the P2P WPS methods
to be accepted first before applying this one.

 gsupplicant/supplicant.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index fd16caf..83d4c1c 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3203,12 +3203,15 @@ static void p2p_device_config_result(const char *error,
 static void p2p_device_config_params(DBusMessageIter *iter, void *user_data)
 {
struct supplicant_p2p_dev_config *config = user_data;
+   const char *methods = push_button;
DBusMessageIter dict;
 
supplicant_dbus_dict_open(iter, dict);
 
supplicant_dbus_dict_append_basic(dict, DeviceName,
DBUS_TYPE_STRING, config-device_name);
+   supplicant_dbus_dict_append_basic(dict, ConfigMethods,
+   DBUS_TYPE_STRING, methods);
 
supplicant_dbus_dict_close(iter, dict);
 }
-- 
1.8.5.5

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


[PATCH] manager: Do not recurse one more level for upnp basic type

2014-09-16 Thread Eduardo Abinader
Just recurse one more level for the byte array that
corresponds to bonjour data and not for the variant holding
upnp data. This patch prevents a segmentation fault
occuring by dereferencing null upnp data.
---
 src/manager.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/manager.c b/src/manager.c
index e97921b..17fd7ee 100644
--- a/src/manager.c
+++ b/src/manager.c
@@ -399,19 +399,20 @@ static int parse_peers_service_specs(DBusMessageIter 
*array,
dbus_message_iter_next(entry);
 
dbus_message_iter_recurse(entry, inter);
-   dbus_message_iter_recurse(inter, value);
 
if  (!g_strcmp0(key, BonjourResponse)) {
+   dbus_message_iter_recurse(inter, value);
dbus_message_iter_get_fixed_array(value,
spec, spec_len);
} else if (!g_strcmp0(key, BonjourQuery)) {
+   dbus_message_iter_recurse(inter, value);
dbus_message_iter_get_fixed_array(value,
query, query_len);
} else if (!g_strcmp0(key, UpnpService)) {
-   dbus_message_iter_get_basic(value, spec);
+   dbus_message_iter_get_basic(inter, spec);
*spec_len = strlen((const char *)*spec)+1;
} else if (!g_strcmp0(key, UpnpVersion)) {
-   dbus_message_iter_get_basic(value, version);
+   dbus_message_iter_get_basic(inter, version);
} else
return -EINVAL;
 
-- 
1.9.1

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