date:20140717

Re: [PATCH v3] service: Changes to favorite property also affect the autoconnect property.

2014-07-17 Thread Aaron McCarthy

On Tue, 15 Jul 2014 11:42:12 Jukka Rissanen wrote:
 On ti, 2014-07-15 at 10:29 +1000, Aaron McCarthy wrote:
  The AutoConnect property is always reported as false if Favorite is
  false. Emit property changed for AutoConnect when Favorite changes.
  When emitting the changed signal use the same logic as GetProperties in
  determining the value to return for AutoConnect.
 
 If favorite changes to false (meaning that service is then removed and
 not connectable any longer), then sending autoconnect value does not
 make much sense as favorite==false implies that already.

By not sending the autoconnect value the application needs to be coded to 
handle this implied relationship between favorite and autoconnect. By sending 
the signal the application can trust that the notified value of autoconnect is 
correct.

In our implementation GetProperties is hardly ever called. It may be called 
once at construction time to get the initial state if it hasn't already been 
initialise from the service list retrieved from the manager object. Afterwards 
property are kept up to date in response to property changed notifications 
from DBus.

 If favorite changes to true (meaning that user connected to it
 successfully again), then this kind of patch has some merit because it
 might be good to know the value of autoconnect without a call to
 GetProperties.
 
 I wonder would it make more sense to call autoconnect_changed() in
 service_indicate_state() when calling
 __connman_service_set_favorite(service, true), instead of tweaking the
 set favorite function.
 The favorite flag is also called from config.c but at that point the
 service is not yet connected and the autoconnect flag would anyway be
 sent from service_indicate_state() when the service enters it.
 
 So at the moment I am inclined to say nak to this patch as it is now.

Cheers,

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

Re: [PATCH v3] service: Changes to favorite property also affect the autoconnect property.

2014-07-17 Thread Jukka Rissanen

Hi Aaron,

On to, 2014-07-17 at 16:42 +1000, Aaron McCarthy wrote:
 On Tue, 15 Jul 2014 11:42:12 Jukka Rissanen wrote:
  On ti, 2014-07-15 at 10:29 +1000, Aaron McCarthy wrote:
   The AutoConnect property is always reported as false if Favorite is
   false. Emit property changed for AutoConnect when Favorite changes.
   When emitting the changed signal use the same logic as GetProperties in
   determining the value to return for AutoConnect.
  
  If favorite changes to false (meaning that service is then removed and
  not connectable any longer), then sending autoconnect value does not
  make much sense as favorite==false implies that already.
 
 By not sending the autoconnect value the application needs to be coded to 
 handle this implied relationship between favorite and autoconnect. By sending 
 the signal the application can trust that the notified value of autoconnect 
 is 
 correct.
 
 In our implementation GetProperties is hardly ever called. It may be called 
 once at construction time to get the initial state if it hasn't already been 
 initialise from the service list retrieved from the manager object. 
 Afterwards 
 property are kept up to date in response to property changed notifications 
 from DBus.
 
  If favorite changes to true (meaning that user connected to it
  successfully again), then this kind of patch has some merit because it
  might be good to know the value of autoconnect without a call to
  GetProperties.
  
  I wonder would it make more sense to call autoconnect_changed() in
  service_indicate_state() when calling
  __connman_service_set_favorite(service, true), instead of tweaking the
  set favorite function.
  The favorite flag is also called from config.c but at that point the
  service is not yet connected and the autoconnect flag would anyway be
  sent from service_indicate_state() when the service enters it.
  
  So at the moment I am inclined to say nak to this patch as it is now.
 
 Cheers,
 

I think we need to leave this to Patrik to decide if he wants to take
this or not. I have no strong opinion against the patch anyway.


Cheers,
Jukka


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

[PATCH 0/5 v2] Handle P2P dhcp role properly

2014-07-17 Thread Tomasz Bursztyka

Hello,

- v2: Applied comments from Jukka about v1 

Here is the patch-set adding the logic when the local device needs to
be the dhcp server on a P2P connection, and not a dhcp client.

First case here is when the local device ends up as the P2P group owner.

Please review,

Tomasz Bursztyka (5):
  gsupplicant: Add an helper to know if a peer is connected as client or
not
  peer: Add a function to tell the dhcp role of the peer
  wifi: Set peer's connection master status when on configuration state
  peer: Run dhcp server when peer is supposed to be the connection
master
  peer: Provide the proper ipv4 settings when peer is the dhcp server

 gsupplicant/gsupplicant.h |   1 +
 gsupplicant/supplicant.c  |  22 ++
 include/peer.h|   1 +
 plugins/wifi.c|   2 +
 src/peer.c| 180 ++
 5 files changed, 193 insertions(+), 13 deletions(-)

-- 
1.8.5.5

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

[PATCH 4/5] peer: Run dhcp server when peer is supposed to be the connection master

2014-07-17 Thread Tomasz Bursztyka

This will finally handle the default case when our local device ends up
as the P2P group owner and thus needs to be the dhcp server as well.
---
 src/peer.c | 143 -
 1 file changed, 132 insertions(+), 11 deletions(-)

diff --git a/src/peer.c b/src/peer.c
index 3a6f178..0551a8c 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -25,6 +25,7 @@
 
 #include errno.h
 #include gdbus.h
+#include gdhcp/gdhcp.h
 
 #include connman.h
 
@@ -52,8 +53,103 @@ struct connman_peer {
DBusMessage *pending;
bool registered;
bool connection_master;
+   struct connman_ippool *ip_pool;
+   GDHCPServer *dhcp_server;
 };
 
+static void stop_dhcp_server(struct connman_peer *peer)
+{
+   DBG();
+
+   if (peer-dhcp_server) {
+   g_dhcp_server_stop(peer-dhcp_server);
+   g_dhcp_server_unref(peer-dhcp_server);
+   }
+   peer-dhcp_server = NULL;
+
+   if (peer-ip_pool)
+   __connman_ippool_unref(peer-ip_pool);
+   peer-ip_pool = NULL;
+}
+
+static void dhcp_server_debug(const char *str, void *data)
+{
+   connman_info(%s: %s\n, (const char *) data, str);
+}
+
+static gboolean dhcp_server_started(gpointer data)
+{
+   struct connman_peer *peer = data;
+
+   connman_peer_set_state(peer, CONNMAN_PEER_STATE_READY);
+   connman_peer_unref(peer);
+
+   return FALSE;
+}
+
+static int start_dhcp_server(struct connman_peer *peer)
+{
+   const char *start_ip, *end_ip;
+   GDHCPServerError dhcp_error;
+   const char *broadcast;
+   const char *gateway;
+   const char *subnet;
+   int prefixlen;
+   int index;
+   int err;
+
+   DBG();
+
+   err = -ENOMEM;
+
+   if (peer-sub_device)
+   index = connman_device_get_index(peer-sub_device);
+   else
+   index = connman_device_get_index(peer-device);
+
+   peer-ip_pool = __connman_ippool_create(index, 2, 1, NULL, NULL);
+   if (!peer-ip_pool)
+   goto error;
+
+   gateway = __connman_ippool_get_gateway(peer-ip_pool);
+   subnet = __connman_ippool_get_subnet_mask(peer-ip_pool);
+   broadcast = __connman_ippool_get_broadcast(peer-ip_pool);
+   start_ip = __connman_ippool_get_start_ip(peer-ip_pool);
+   end_ip = __connman_ippool_get_end_ip(peer-ip_pool);
+
+   prefixlen = connman_ipaddress_calc_netmask_len(subnet);
+
+   err = __connman_inet_modify_address(RTM_NEWADDR,
+   NLM_F_REPLACE | NLM_F_ACK, index, AF_INET,
+   gateway, NULL, prefixlen, broadcast);
+   if (err  0)
+   goto error;
+
+   peer-dhcp_server = g_dhcp_server_new(G_DHCP_IPV4, index, dhcp_error);
+   if (!peer-dhcp_server)
+   goto error;
+
+   g_dhcp_server_set_debug(peer-dhcp_server,
+   dhcp_server_debug, Peer DHCP server);
+   g_dhcp_server_set_lease_time(peer-dhcp_server, 3600);
+   g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_SUBNET, subnet);
+   g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_ROUTER, gateway);
+   g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_DNS_SERVER, NULL);
+   g_dhcp_server_set_ip_range(peer-dhcp_server, start_ip, end_ip);
+
+   err = g_dhcp_server_start(peer-dhcp_server);
+   if (err  0)
+   goto error;
+
+   g_timeout_add_seconds(0, dhcp_server_started, connman_peer_ref(peer));
+
+   return 0;
+
+error:
+   stop_dhcp_server(peer);
+   return err;
+}
+
 static void reply_pending(struct connman_peer *peer, int error)
 {
if (!peer-pending)
@@ -83,6 +179,8 @@ static void peer_free(gpointer data)
peer-ipconfig = NULL;
}
 
+   stop_dhcp_server(peer);
+
if (peer-device) {
connman_device_unref(peer-device);
peer-device = NULL;
@@ -341,11 +439,14 @@ static int peer_disconnect(struct connman_peer *peer)
 
reply_pending(peer, ECONNABORTED);
 
+   if (peer-connection_master)
+   stop_dhcp_server(peer);
+   else
+   __connman_dhcp_stop(peer-ipconfig);
+
if (peer_driver-disconnect)
err = peer_driver-disconnect(peer);
 
-   __connman_dhcp_stop(peer-ipconfig);
-
return err;
 }
 
@@ -516,6 +617,17 @@ error:
connman_peer_set_state(peer, CONNMAN_PEER_STATE_FAILURE);
 }
 
+static int start_dhcp_client(struct connman_peer *peer)
+{
+   if (peer-sub_device)
+   __connman_ipconfig_set_index(peer-ipconfig,
+   connman_device_get_index(peer-sub_device));
+
+   __connman_ipconfig_enable(peer-ipconfig);
+
+   return __connman_dhcp_start(peer-ipconfig, NULL, dhcp_callback, peer);
+}
+
 int connman_peer_set_state(struct connman_peer *peer,
enum connman_peer_state new_state)
 {
@@ -534,13 +646,10 @@ int

[PATCH 1/5] gsupplicant: Add an helper to know if a peer is connected as client or not

2014-07-17 Thread Tomasz Bursztyka

This is will be useful for wifi plugin and peer core code to run dhcp as
a client or as a server.
---
 gsupplicant/gsupplicant.h |  1 +
 gsupplicant/supplicant.c  | 22 ++
 2 files changed, 23 insertions(+)

diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index 82c9bc6..387a3aa 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -296,6 +296,7 @@ bool g_supplicant_peer_is_wps_pbc(GSupplicantPeer *peer);
 bool g_supplicant_peer_is_wps_pin(GSupplicantPeer *peer);
 bool g_supplicant_peer_is_in_a_group(GSupplicantPeer *peer);
 GSupplicantInterface *g_supplicant_peer_get_group_interface(GSupplicantPeer 
*peer);
+bool g_supplicant_peer_is_client(GSupplicantPeer *peer);
 
 struct _GSupplicantCallbacks {
void (*system_ready) (void);
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 8324cc2..c6342d5 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -1098,6 +1098,28 @@ GSupplicantInterface 
*g_supplicant_peer_get_group_interface(GSupplicantPeer *pee
return (GSupplicantInterface *) peer-current_group_iface;
 }
 
+bool g_supplicant_peer_is_client(GSupplicantPeer *peer)
+{
+   GSupplicantGroup *group;
+   GSList *list;
+
+   if (!peer)
+   return false;
+
+   for (list = peer-groups; list; list = list-next) {
+   group = list-data;
+
+   if (group-role != G_SUPPLICANT_GROUP_ROLE_CLIENT ||
+   group-orig_interface != peer-interface)
+   continue;
+
+   if (group-interface == peer-current_group_iface)
+   return true;
+   }
+
+   return false;
+}
+
 static void merge_network(GSupplicantNetwork *network)
 {
GString *str;
-- 
1.8.5.5

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

[PATCH 2/5] peer: Add a function to tell the dhcp role of the peer

2014-07-17 Thread Tomasz Bursztyka

This will be used afterwards, in configuration state, to start dhcp as a
client or as a server.
---
 include/peer.h | 1 +
 src/peer.c | 9 +
 2 files changed, 10 insertions(+)

diff --git a/include/peer.h b/include/peer.h
index cdaee49..720d65b 100644
--- a/include/peer.h
+++ b/include/peer.h
@@ -58,6 +58,7 @@ void connman_peer_set_device(struct connman_peer *peer,
 struct connman_device *connman_peer_get_device(struct connman_peer *peer);
 void connman_peer_set_sub_device(struct connman_peer *peer,
struct connman_device *device);
+void connman_peer_set_as_master(struct connman_peer *peer, bool master);
 int connman_peer_set_state(struct connman_peer *peer,
enum connman_peer_state new_state);
 
diff --git a/src/peer.c b/src/peer.c
index a905f04..3a6f178 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -51,6 +51,7 @@ struct connman_peer {
struct connman_ipconfig *ipconfig;
DBusMessage *pending;
bool registered;
+   bool connection_master;
 };
 
 static void reply_pending(struct connman_peer *peer, int error)
@@ -484,6 +485,14 @@ void connman_peer_set_sub_device(struct connman_peer *peer,
peer-sub_device = device;
 }
 
+void connman_peer_set_as_master(struct connman_peer *peer, bool master)
+{
+   if (!peer || !is_connecting(peer))
+   return;
+
+   peer-connection_master = master;
+}
+
 static void dhcp_callback(struct connman_ipconfig *ipconfig,
struct connman_network *network,
bool success, gpointer data)
-- 
1.8.5.5

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

[PATCH 3/5] wifi: Set peer's connection master status when on configuration state

2014-07-17 Thread Tomasz Bursztyka

This will let peer core starting dhcp either as a server or as a client.
---
 plugins/wifi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/plugins/wifi.c b/plugins/wifi.c
index ba4ce66..eb1fad0 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2373,6 +2373,8 @@ static void peer_changed(GSupplicantPeer *peer,
if (!g_wifi)
return;
 
+   connman_peer_set_as_master(connman_peer,
+   !g_supplicant_peer_is_client(peer));
connman_peer_set_sub_device(connman_peer, g_wifi-device);
}
 
-- 
1.8.5.5

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

[PATCH 5/5] peer: Provide the proper ipv4 settings when peer is the dhcp server

2014-07-17 Thread Tomasz Bursztyka

From core point of view, getting the IPv4 settings is different wheather
the peer is running dhcp as a client or as a server. On client mode it
can put those settings into DBus from its ipconfig structure. On server
mode, it has to get the details from the dhcp server structure and build
the DBus content by itself. In the end this does not change anything for
the end-user.
---
 src/peer.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/src/peer.c b/src/peer.c
index 0551a8c..39877ec 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -241,14 +241,38 @@ static bool allow_property_changed(struct connman_peer 
*peer)
return true;
 }
 
+static void append_dhcp_server_ipv4(DBusMessageIter *iter, void *user_data)
+{
+   struct connman_peer *peer = user_data;
+   const char *str = dhcp;
+   const char *gateway;
+   const char *subnet;
+
+   if (!peer-ip_pool)
+   return;
+
+   gateway = __connman_ippool_get_gateway(peer-ip_pool);
+   subnet = __connman_ippool_get_subnet_mask(peer-ip_pool);
+
+   connman_dbus_dict_append_basic(iter, Method, DBUS_TYPE_STRING, str);
+   connman_dbus_dict_append_basic(iter, Address,
+   DBUS_TYPE_STRING, gateway);
+   connman_dbus_dict_append_basic(iter, Netmask,
+   DBUS_TYPE_STRING, subnet);
+   connman_dbus_dict_append_basic(iter, Gateway,
+   DBUS_TYPE_STRING, gateway);
+}
+
 static void append_ipv4(DBusMessageIter *iter, void *user_data)
 {
struct connman_peer *peer = user_data;
 
-   if (peer-state != CONNMAN_PEER_STATE_READY)
+   if (!is_connected(peer))
return;
 
-   if (peer-ipconfig)
+   if (peer-connection_master)
+   append_dhcp_server_ipv4(iter, peer);
+   else if (peer-ipconfig)
__connman_ipconfig_append_ipv4(peer-ipconfig, iter);
 }
 
-- 
1.8.5.5

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

Re: [PATCH 3/5] peer: Run dhcp server when peer is supposed to be the connection master

2014-07-17 Thread Tomasz Bursztyka


Hi Jukka,


+   peer-ip_pool = __connman_ippool_create(index, 2, 1, NULL, NULL);

Do we only support one address (==one client) here?



True. Currently it supports only one. In fact: if you call Connect() 
from DBus, it checks
all the peers from same device. If one is connecting/connected: it 
disconnects it first

before proceeding with this connection request.

This will change in the future, the logic in gsupplicant/wifi-plugin is 
multiple-connection

ready at this point.

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

Re: [PATCH v4] gdhcp: Request an actual IP address when rebinding

2014-07-17 Thread Jukka Rissanen

Hi Justin,

On ke, 2014-07-16 at 11:12 -0700, Justin Maggard wrote:
 We need to specify a requested IP address when our DHCP client state
 is REBINDING as well as REQUESTING and REBOOTING; or else we end up
 sending a DHCP request for 0.0.0.0, which generally just gets ignored.
 ---
  gdhcp/client.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/gdhcp/client.c b/gdhcp/client.c
 index 47ce2e8..8a9e3b8 100644
 --- a/gdhcp/client.c
 +++ b/gdhcp/client.c
 @@ -484,13 +484,13 @@ static int send_request(GDHCPClient *dhcp_client)
  
   add_send_options(dhcp_client, packet);
  
 - if (dhcp_client-state == RENEWING) {
 + if (dhcp_client-state == RENEWING || dhcp_client-state == REBINDING)
   packet.ciaddr = htonl(dhcp_client-requested_ip);
  
 + if (dhcp_client-state == RENEWING)
   return dhcp_send_kernel_packet(packet,
   dhcp_client-requested_ip, CLIENT_PORT,
   dhcp_client-server_ip, SERVER_PORT);
 - }
  
   return dhcp_send_raw_packet(packet, INADDR_ANY, CLIENT_PORT,
   INADDR_BROADCAST, SERVER_PORT,

Ack to this, looks good now.


Cheers,
Jukka


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

Re: [PATCH] gdhcp: adjust discovery/request timeout and retry values

2014-07-17 Thread Jukka Rissanen

Hi Pasi,

On ke, 2014-07-16 at 22:30 +0300, pasi.sjoh...@jolla.com wrote:
 From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
 
 Some dhcp servers are acting lazy (eg. Buffalo WBMR-G125)
 therefore 3 second timeout value for discovery or request
 is not enough. Adjusting the timeout value from 3 seconds
 to 5 will fix the problem together with adjusting the
 retry value not to increase the total time for waiting
 for getting the lease.
 ---
  gdhcp/client.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/gdhcp/client.c b/gdhcp/client.c
 index 47ce2e8..7b47ad2 100644
 --- a/gdhcp/client.c
 +++ b/gdhcp/client.c
 @@ -47,11 +47,11 @@
  #include common.h
  #include ipv4ll.h
  
 -#define DISCOVER_TIMEOUT 3
 -#define DISCOVER_RETRIES 10
 +#define DISCOVER_TIMEOUT 5
 +#define DISCOVER_RETRIES 6
  
 -#define REQUEST_TIMEOUT 3
 -#define REQUEST_RETRIES 5
 +#define REQUEST_TIMEOUT 5
 +#define REQUEST_RETRIES 3
  
  typedef enum _listen_mode {
   L_NONE,

The numbers look sane, ACK to this.


Cheers,
Jukka


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

Re: [PATCH 0/5 v2] Handle P2P dhcp role properly

2014-07-17 Thread Daniel Wagner


Hi Tomasz,

On 07/17/2014 03:00 PM, Tomasz Bursztyka wrote:

Hello,

- v2: Applied comments from Jukka about v1


Looks good. I went ahead and applied this version.

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

Re: [PATCH v4] gdhcp: Request an actual IP address when rebinding

2014-07-17 Thread Daniel Wagner


Hi Justin,

On 07/17/2014 03:47 PM, Jukka Rissanen wrote:

Hi Justin,

On ke, 2014-07-16 at 11:12 -0700, Justin Maggard wrote:

We need to specify a requested IP address when our DHCP client state
is REBINDING as well as REQUESTING and REBOOTING; or else we end up
sending a DHCP request for 0.0.0.0, which generally just gets ignored.
---
  gdhcp/client.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gdhcp/client.c b/gdhcp/client.c
index 47ce2e8..8a9e3b8 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -484,13 +484,13 @@ static int send_request(GDHCPClient *dhcp_client)

add_send_options(dhcp_client, packet);

-   if (dhcp_client-state == RENEWING) {
+   if (dhcp_client-state == RENEWING || dhcp_client-state == REBINDING)
packet.ciaddr = htonl(dhcp_client-requested_ip);

+   if (dhcp_client-state == RENEWING)
return dhcp_send_kernel_packet(packet,
dhcp_client-requested_ip, CLIENT_PORT,
dhcp_client-server_ip, SERVER_PORT);
-   }

return dhcp_send_raw_packet(packet, INADDR_ANY, CLIENT_PORT,
INADDR_BROADCAST, SERVER_PORT,


Ack to this, looks good now.


Patch applied.

Thanks,
Daniel

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

Re: [PATCH] gdhcp: adjust discovery/request timeout and retry values

2014-07-17 Thread Daniel Wagner


Hi Pasi,

On 07/17/2014 04:36 PM, Jukka Rissanen wrote:

On ke, 2014-07-16 at 22:30 +0300, pasi.sjoh...@jolla.com wrote:

From: Pasi Sjöholm pasi.sjoh...@jollamobile.com

Some dhcp servers are acting lazy (eg. Buffalo WBMR-G125)
therefore 3 second timeout value for discovery or request
is not enough. Adjusting the timeout value from 3 seconds
to 5 will fix the problem together with adjusting the
retry value not to increase the total time for waiting
for getting the lease.
---
  gdhcp/client.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gdhcp/client.c b/gdhcp/client.c
index 47ce2e8..7b47ad2 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -47,11 +47,11 @@
  #include common.h
  #include ipv4ll.h

-#define DISCOVER_TIMEOUT 3
-#define DISCOVER_RETRIES 10
+#define DISCOVER_TIMEOUT 5
+#define DISCOVER_RETRIES 6

-#define REQUEST_TIMEOUT 3
-#define REQUEST_RETRIES 5
+#define REQUEST_TIMEOUT 5
+#define REQUEST_RETRIES 3

  typedef enum _listen_mode {
L_NONE,


The numbers look sane, ACK to this.


Patch applied.

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

ever ready state

2014-07-17 Thread Henrique Abreu

Hi,

I installed connman from git on my Arch, but I'm having an issue.

My wifi connection never goes to Online state, it's stuck on Ready.
This is 100% reproducible, whenever I boot the system it never goes
Online. It only goes if I disable and re-enable my wifi.

Can I trigger an Online check manually? Or do you guys have any other
suggestion on how I can fix this?

Regards,

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

Re: [PATCH v3] service: Changes to favorite property also affect the autoconnect property.

Re: [PATCH v3] service: Changes to favorite property also affect the autoconnect property.

[PATCH 0/5 v2] Handle P2P dhcp role properly

[PATCH 4/5] peer: Run dhcp server when peer is supposed to be the connection master

[PATCH 1/5] gsupplicant: Add an helper to know if a peer is connected as client or not

[PATCH 2/5] peer: Add a function to tell the dhcp role of the peer

[PATCH 3/5] wifi: Set peer's connection master status when on configuration state

[PATCH 5/5] peer: Provide the proper ipv4 settings when peer is the dhcp server

Re: [PATCH 3/5] peer: Run dhcp server when peer is supposed to be the connection master

Re: [PATCH v4] gdhcp: Request an actual IP address when rebinding

Re: [PATCH] gdhcp: adjust discovery/request timeout and retry values

Re: [PATCH 0/5 v2] Handle P2P dhcp role properly

Re: [PATCH v4] gdhcp: Request an actual IP address when rebinding

Re: [PATCH] gdhcp: adjust discovery/request timeout and retry values

ever ready state

15 matches

Site Navigation

Mail list logo

Footer information