Re: [PATCH] gdhcp: set secs in a RFC 951- and 2131-compliant manner
Hi Grant,
> This patch sets the BOOTP secs field in a RFC 951- and 2131-compliant
> manner for DHCPv4 DISCOVER and REQUEST/SELECT packets.
>
> ---
> Certain DHCP servers, such as that implemented in Mac OS X (< 10.7)
> for its "Internet Sharing" feature, refuse to issue a DHCP lease to
> clients that have not set a non-zero value in their DISCOVER or
> REQUEST packets.
>
> Side-by-side packet analysis of Mac OS X, iOS, Android, ISC and
> Windows clients show that these clients set the BOOTP 'secs' field and
> are successfully issued a DHCP lease by Mac OS X. By contrast, a
> connman-based client will issue 10 back-to-back DISCOVER packets and
> will not be returned a DHCP OFFER from the server.
make this all a commit message. It is useful information.
>
> gdhcp/client.c | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/gdhcp/client.c b/gdhcp/client.c
> index a3b4b8a..761e6f9 100644
> --- a/gdhcp/client.c
> +++ b/gdhcp/client.c
> @@ -85,6 +85,7 @@ struct _GDHCPClient {
> char *interface;
> uint8_t mac_address[6];
> uint32_t xid;
> + time_t start;
> uint32_t server_ip;
> uint32_t requested_ip;
> char *assigned_ip;
> @@ -339,6 +340,14 @@ static void add_send_options(GDHCPClient *dhcp_client,
> add_binary_option, packet);
> }
>
> +/* Return an RFC 951- and 2131-complaint BOOTP 'secs' value that
> + * represents the number of seconds elapsed from the start of
> + * attempting DHCP. */
> +static uint16_t dhcp_attempt_secs(GDHCPClient *dhcp_client)
> +{
> + return htons(MIN(time(0) - dhcp_client->start, UINT16_MAX));
> +}
> +
Fix the indentation here please.
> static int send_discover(GDHCPClient *dhcp_client, uint32_t requested)
> {
> struct dhcp_packet packet;
> @@ -348,6 +357,7 @@ static int send_discover(GDHCPClient *dhcp_client,
> uint32_t requested)
> init_packet(dhcp_client, &packet, DHCPDISCOVER);
>
> packet.xid = dhcp_client->xid;
> + packet.secs = dhcp_attempt_secs(dhcp_client);
>
> if (requested)
> dhcp_add_simple_option(&packet, DHCP_REQUESTED_IP, requested);
> @@ -374,6 +384,7 @@ static int send_select(GDHCPClient *dhcp_client)
> init_packet(dhcp_client, &packet, DHCPREQUEST);
>
> packet.xid = dhcp_client->xid;
> + packet.secs = dhcp_attempt_secs(dhcp_client);
>
> dhcp_add_simple_option(&packet, DHCP_REQUESTED_IP,
> dhcp_client->requested_ip);
> @@ -2240,7 +2251,7 @@ int g_dhcp_client_start(GDHCPClient *dhcp_client, const
> char *last_address)
> return re;
>
> dhcp_client->xid = rand();
> + dhcp_client->start = time(0);
> }
>
> if (last_address == NULL) {
Rest looks fine to me.
Regards
Marcel
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
[PATCH] gdhcp: set secs in a RFC 951- and 2131-compliant manner
This patch sets the BOOTP secs field in a RFC 951- and 2131-compliant
manner for DHCPv4 DISCOVER and REQUEST/SELECT packets.
---
Certain DHCP servers, such as that implemented in Mac OS X (< 10.7)
for its "Internet Sharing" feature, refuse to issue a DHCP lease to
clients that have not set a non-zero value in their DISCOVER or
REQUEST packets.
Side-by-side packet analysis of Mac OS X, iOS, Android, ISC and
Windows clients show that these clients set the BOOTP 'secs' field and
are successfully issued a DHCP lease by Mac OS X. By contrast, a
connman-based client will issue 10 back-to-back DISCOVER packets and
will not be returned a DHCP OFFER from the server.
gdhcp/client.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/gdhcp/client.c b/gdhcp/client.c
index a3b4b8a..761e6f9 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -85,6 +85,7 @@ struct _GDHCPClient {
char *interface;
uint8_t mac_address[6];
uint32_t xid;
+ time_t start;
uint32_t server_ip;
uint32_t requested_ip;
char *assigned_ip;
@@ -339,6 +340,14 @@ static void add_send_options(GDHCPClient *dhcp_client,
add_binary_option, packet);
}
+/* Return an RFC 951- and 2131-complaint BOOTP 'secs' value that
+ * represents the number of seconds elapsed from the start of
+ * attempting DHCP. */
+static uint16_t dhcp_attempt_secs(GDHCPClient *dhcp_client)
+{
+ return htons(MIN(time(0) - dhcp_client->start, UINT16_MAX));
+}
+
static int send_discover(GDHCPClient *dhcp_client, uint32_t requested)
{
struct dhcp_packet packet;
@@ -348,6 +357,7 @@ static int send_discover(GDHCPClient *dhcp_client, uint32_t
requested)
init_packet(dhcp_client, &packet, DHCPDISCOVER);
packet.xid = dhcp_client->xid;
+ packet.secs = dhcp_attempt_secs(dhcp_client);
if (requested)
dhcp_add_simple_option(&packet, DHCP_REQUESTED_IP, requested);
@@ -374,6 +384,7 @@ static int send_select(GDHCPClient *dhcp_client)
init_packet(dhcp_client, &packet, DHCPREQUEST);
packet.xid = dhcp_client->xid;
+ packet.secs = dhcp_attempt_secs(dhcp_client);
dhcp_add_simple_option(&packet, DHCP_REQUESTED_IP,
dhcp_client->requested_ip);
@@ -2240,7 +2251,7 @@ int g_dhcp_client_start(GDHCPClient *dhcp_client, const
char *last_address)
return re;
dhcp_client->xid = rand();
+ dhcp_client->start = time(0);
}
if (last_address == NULL) {
--
1.7.8.2
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: ntp synchronization in READY state.
Hello Marcel, Thanks for your response. Is there a hard and fast way i can get this behaviour changed. If required, can do away with the WISPr/online check so that it always returns SUCCESS. You see the NTP sync is extremely important in my case. Regards ~Sameer On Mon, Feb 27, 2012 at 10:42 PM, Marcel Holtmann wrote: > Hi Naik, > >> According to my understanding NTP synchronization will occur in >> connman once service state is CONNMAN_SERVICE_STATE_ONLINE. Further >> service will enter the online state once connman can communicate with >> http://ipv4.connman.net/online/status.html. >> >> However in my case, generally an NTP server announced via dhcp and is >> present on the local network. My device may not necessarily be >> connected to the internet. So i need to start the ntp synchronization >> before connman enters the ONLINE state. > > it is actually not that simple. If the NTP server is announced via DHCP > and is in your local network, then we should do this in READY state. > > If it not announced via DHCP, we should try the router in READY state. > > In case we have a static NTP server list and it is in your local network > (either DHCP or static configuration), we should try it in READY state. > > If both are failing and the NTP server is not local, we should be doing > NTP just before going into ONLINE. Meaning after WISPr/online check > declared this connection online. > > Just to be clear here, the ONLINE state that ConnMan announces we are > really online and we tried all possible methods to synchronize the time > for you first. So right now, this is a bug actually. We need to wait NTP > success (or failure) before we go ONLINE. > > Regards > > Marcel > > > ___ > connman mailing list > connman@connman.net > http://lists.connman.net/listinfo/connman ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH] inet: rs_cleanup: ensure data->channel exist before accessing it
Log of segfault:
...
connmand[676]: src/network.c:check_dhcpv6() reply (nil)
connmand[676]: src/network.c:check_dhcpv6() re-send router solicitation 3
connmand[676]: src/inet.c:__connman_inet_ipv6_send_rs()
connmand[676]: Aborting (signal 11) [connmand]
---
The full log are available at
http://parenteses.org/mario/misc/connman-backtrace.txt
src/inet.c | 8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/inet.c b/src/inet.c
index d9e12a9..5bf5f1b 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -1433,9 +1433,11 @@ static const struct in6_addr in6addr_all_routers_mc =
static void rs_cleanup(struct rs_cb_data *data)
{
- g_io_channel_shutdown(data->channel, TRUE, NULL);
- g_io_channel_unref(data->channel);
- data->channel = 0;
+ if (data->channel) {
+ g_io_channel_shutdown(data->channel, TRUE, NULL);
+ g_io_channel_unref(data->channel);
+ data->channel = 0;
+ }
if (data->rs_timeout > 0)
g_source_remove(data->rs_timeout);
--
1.7.9.1
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: [PATCH v3 0/4] Implement ServicesAdded and ServicesRemoved
Got it.. thanks for the fix.
On Mon, Feb 27, 2012 at 10:45 PM, Marcel Holtmann wrote:
> Hi Sameer,
>
>> I am running the git version of connman and have the updates from this
>> thread.
>> I have noticed that when the ServicesRemoved signal is emitted i see
>> the following message throw.
>>
>> (process:780): GLib-GIO-WARNING **: Dropping signal ServicesRemoved of type
>> (ao)
>> since the type from the expected interface is (a{o})
>
> that is a clear but in our introspection data. Fixed that now. The
> signal itself was correct with (ao).
>
> Regards
>
> Marcel
>
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: [PATCH v3 0/4] Implement ServicesAdded and ServicesRemoved
Hi Sameer,
> I am running the git version of connman and have the updates from this thread.
> I have noticed that when the ServicesRemoved signal is emitted i see
> the following message throw.
>
> (process:780): GLib-GIO-WARNING **: Dropping signal ServicesRemoved of type
> (ao)
> since the type from the expected interface is (a{o})
that is a clear but in our introspection data. Fixed that now. The
signal itself was correct with (ao).
Regards
Marcel
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: ntp synchronization in READY state.
Hi Naik, > According to my understanding NTP synchronization will occur in > connman once service state is CONNMAN_SERVICE_STATE_ONLINE. Further > service will enter the online state once connman can communicate with > http://ipv4.connman.net/online/status.html. > > However in my case, generally an NTP server announced via dhcp and is > present on the local network. My device may not necessarily be > connected to the internet. So i need to start the ntp synchronization > before connman enters the ONLINE state. it is actually not that simple. If the NTP server is announced via DHCP and is in your local network, then we should do this in READY state. If it not announced via DHCP, we should try the router in READY state. In case we have a static NTP server list and it is in your local network (either DHCP or static configuration), we should try it in READY state. If both are failing and the NTP server is not local, we should be doing NTP just before going into ONLINE. Meaning after WISPr/online check declared this connection online. Just to be clear here, the ONLINE state that ConnMan announces we are really online and we tried all possible methods to synchronize the time for you first. So right now, this is a bug actually. We need to wait NTP success (or failure) before we go ONLINE. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH] Fix up service ordering
From: Patrik Flykt Hi, Here's a patch fixing service ordering in the ServicesAdded signal. It also lists previously known services and adds an empty dictionary for them. Sorry for the fuzz, Patrik Patrik Flykt (1): service: Keep ordering and send all services in ServicesAdded src/service.c | 144 - 1 files changed, 81 insertions(+), 63 deletions(-) -- 1.7.9 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH] service: Keep ordering and send all services in ServicesAdded
From: Patrik Flykt
Keep services ordering and send also already known services
in ServicesAdded signal.
---
src/service.c | 144 -
1 files changed, 81 insertions(+), 63 deletions(-)
diff --git a/src/service.c b/src/service.c
index a21ee3f..271aace 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1996,27 +1996,43 @@ static void append_properties(DBusMessageIter *dict,
dbus_bool_t limited,
append_provider, service);
}
-static void append_struct(gpointer value, gpointer user_data)
+static void append_struct_service(DBusMessageIter *iter,
+ connman_dbus_append_cb_t function,
+ struct connman_service *service)
{
- struct connman_service *service = value;
- DBusMessageIter *iter = user_data;
DBusMessageIter entry, dict;
- if (service->path == NULL)
- return;
-
dbus_message_iter_open_container(iter, DBUS_TYPE_STRUCT, NULL, &entry);
dbus_message_iter_append_basic(&entry, DBUS_TYPE_OBJECT_PATH,
&service->path);
connman_dbus_dict_open(&entry, &dict);
- append_properties(&dict, TRUE, service);
+ if (function != NULL)
+ function(&dict, service);
connman_dbus_dict_close(&entry, &dict);
dbus_message_iter_close_container(iter, &entry);
}
+static void append_dict_properties(DBusMessageIter *dict, void *user_data)
+{
+ struct connman_service *service = user_data;
+
+ append_properties(dict, TRUE, service);
+}
+
+static void append_struct(gpointer value, gpointer user_data)
+{
+ struct connman_service *service = value;
+ DBusMessageIter *iter = user_data;
+
+ if (service->path == NULL)
+ return;
+
+ append_struct_service(iter, append_dict_properties, service);
+}
+
void __connman_service_list_struct(DBusMessageIter *iter)
{
g_sequence_foreach(service_list, append_struct, iter);
@@ -3263,18 +3279,23 @@ static DBusMessage *reset_counters(DBusConnection *conn,
static struct _services_notify {
int id;
- GSList *added;
- GSList *removed;
+ GHashTable *add;
+ GHashTable *remove;
} *services_notify;
+static void append_removed(gpointer key, gpointer value, gpointer user_data)
+{
+ char *objpath = key;
+ DBusMessageIter *iter = user_data;
+
+ DBG("removed %s", objpath);
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_OBJECT_PATH, &objpath);
+}
+
static void service_send_removed(void)
{
DBusMessage *signal;
DBusMessageIter iter, array;
- GSList *list, *next;
-
- if (services_notify->removed == NULL)
- return;
signal = dbus_message_new_signal(CONNMAN_MANAGER_PATH,
CONNMAN_MANAGER_INTERFACE, "ServicesRemoved");
@@ -3285,57 +3306,57 @@ static void service_send_removed(void)
dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
DBUS_TYPE_OBJECT_PATH_AS_STRING, &array);
- list = services_notify->removed;
- services_notify->removed = NULL;
+ g_hash_table_foreach(services_notify->remove, append_removed, &array);
- while (list != NULL) {
- char *path = list->data;
- DBG("removing %s", path);
- next = list->next;
- dbus_message_iter_append_basic(&array,
- DBUS_TYPE_OBJECT_PATH, &list->data);
- g_free(list->data);
- g_slist_free_1(list);
- list = next;
- }
dbus_message_iter_close_container(&iter, &array);
dbus_connection_send(connection, signal, NULL);
dbus_message_unref(signal);
}
-static void append_service_structs(DBusMessageIter *iter, void *user_data)
+static void service_send_added_foreach(gpointer data, gpointer user_data)
{
- GSList *list = user_data;
- GSList *next;
+ struct connman_service *service = data;
+ DBusMessageIter *iter = user_data;
+ gpointer value;
+
+ if (service == NULL || service->path == NULL) {
+ DBG("service %p or path is NULL", service);
+ return;
+ }
- while (list != NULL) {
- struct connman_service *srv = list->data;
- DBG("adding %s", srv->path);
- next = list->next;
- append_struct(list->data, iter);
- g_slist_free_1(list);
- list = next;
+ value = g_hash_table_lookup(services_notify->remove, service->path);
+ if (GPOINTER_TO_INT(value) == TRUE) {
+ g_hash_table_remove(services_notify->remove, service->path);
+ return;
}
+
+ DBG("added %s", service->path);
+
+ if (g_hash_table_lookup(services_notify->add, service->path) != NULL) {
+ append_struct(s
ntp synchronization in READY state.
Hello,
According to my understanding NTP synchronization will occur in
connman once service state is CONNMAN_SERVICE_STATE_ONLINE. Further
service will enter the online state once connman can communicate with
http://ipv4.connman.net/online/status.html.
However in my case, generally an NTP server announced via dhcp and is
present on the local network. My device may not necessarily be
connected to the internet. So i need to start the ntp synchronization
before connman enters the ONLINE state.
For this i made the following change:
src/service.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/service.c b/src/service.c
index a21ee3f..e093340 100644
--- a/src/service.c
+++ b/src/service.c
@@ -4052,9 +4052,6 @@ static int service_indicate_state(struct
connman_service *service)
}
}
- if (new_state == CONNMAN_SERVICE_STATE_ONLINE)
- __connman_timeserver_sync(service);
-
if (new_state == CONNMAN_SERVICE_STATE_IDLE) {
connman_bool_t reconnect;
@@ -4157,6 +4154,9 @@ static int service_indicate_state(struct
connman_service *service)
if (new_state == CONNMAN_SERVICE_STATE_ONLINE)
default_changed();
+ if (new_state == CONNMAN_SERVICE_STATE_READY)
+ __connman_timeserver_sync(service);
+
return 0;
}
That is to say, start __connman_timeserver_sync once we are in the
READY state and dont wait for connman to go to ONLINE state.
But after this change, while trying to scan a wifi technology i
receiving the error "GDBus.Error:net.connman.Error.NoCarrier: No
carrier" very frequently and i am required to stop connman and start
it again after which it is fine. I am finding it difficult to
understand why this is happening. I had made a similar edit for
connman-0.78 and it was working fine. Please find the attached
connman.log
Looking forward to your response.
Regards
~Sameer
$ connmand -n -d -W wext
connmand[743]: Connection Manager version 0.78
connmand[743]: src/dbus.c:__connman_dbus_init()
connmand[743]: src/storage.c:storage_load() Loading /opt/resource/etc/connman/settings
connmand[743]: src/technology.c:__connman_technology_init()
connmand[743]: src/storage.c:storage_load() Loading /opt/resource/etc/connman/settings
connmand[743]: src/notifier.c:__connman_notifier_init()
connmand[743]: src/service.c:__connman_service_init()
connmand[743]: src/provider.c:__connman_provider_init()
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x4987e0 name provider
connmand[743]: src/network.c:__connman_network_init()
connmand[743]: src/device.c:__connman_device_init()
connmand[743]: src/agent.c:__connman_agent_init()
connmand[743]: src/ippool.c:__connman_ippool_init()
connmand[743]: src/iptables.c:__connman_iptables_init()
connmand[743]: src/nat.c:__connman_nat_init()
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x498b50 name nat
connmand[743]: src/iptables.c:__connman_iptables_command() command -t nat -F POSTROUTING argc 5
connmand[743]: src/iptables.c:iptables_init() nat
connmand[743]: src/iptables.c:iptables_command() Flush chain POSTROUTING
connmand[743]: src/iptables.c:__connman_iptables_commit() nat
connmand[743]: src/tethering.c:__connman_tethering_init()
connmand[743]: src/counter.c:__connman_counter_init()
connmand[743]: src/manager.c:__connman_manager_init()
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x498480 name manager
connmand[743]: src/config.c:__connman_config_init()
connmand[743]: src/config.c:read_configs()
connmand[743]: src/stats.c:__connman_stats_init()
connmand[743]: src/clock.c:__connman_clock_init()
connmand[743]: src/timezone.c:__connman_timezone_init()
connmand[743]: src/timezone.c:__connman_timezone_lookup() sysconfig zone (null)
connmand[743]: src/timezone.c:__connman_timezone_lookup() localtime zone (null)
connmand[743]: src/resolver.c:__connman_resolver_init() dnsproxy 1
connmand[743]: src/dnsproxy.c:__connman_dnsproxy_init()
connmand[743]: src/dnsproxy.c:__connman_dnsproxy_add_listener() interface lo
connmand[743]: src/dnsproxy.c:create_dns_listener() interface lo
connmand[743]: No IPv6 support; DNS proxy listening only on Legacy IP
connmand[743]: Failed to bind UDP listener interface
connmand[743]: src/dnsproxy.c:create_dns_listener() interface lo
connmand[743]: No IPv6 support; DNS proxy listening only on Legacy IP
connmand[743]: Failed to bind TCP listener interface
connmand[743]: src/resolver.c:__connman_resolvfile_append() interface lo server 127.0.0.1
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x498b20 name dnsproxy
connmand[743]: src/ipconfig.c:__connman_ipconfig_init()
connmand[743]: src/rtnl.c:__connman_rtnl_init()
connmand[743]: src/task.c:__connman_task_init()
connmand[743]: src/proxy.c:__connman_proxy_init()
connmand[743]: src/detect.c:__connman_detect_init()
connmand[743]: src/rtnl.c:connman_rtnl_register() rtnl 0x498810
Re: [PATCH v3 0/4] Implement ServicesAdded and ServicesRemoved
Hi Patrik, > On Sat, 2012-02-25 at 18:02 +0100, Daniel Wagner wrote: > > the ServicesAdded array does not containn 'old' servces. According the > > documentation this array should contain all services in the right > > order. > > That's a good point. First the document says: > "...The array is a list of services that is sorted with existing > services containing an empty dictionary and new services containing the > properties." > > But then it says: > "This signal will only inform about added services...", which after a > third reading probably intends to refer to the difference of "added" vs. > "removed" signals if the first part is to be true as well. > > Darn, this is rather confusing. it is actually simple, but you need to look at it from a work flow of the client application. The goal is that the client, can remove no longer existing services and we don't have to worry about them anymore. So ServicesRemoved will always be send before ServiceAdded. That is a simplification for the client to not have to compare the lists to find the ones that are no longer present. So yes, ServiceAdded only contains current existing and new services. It does not directly inform about removed services. That would be only implicit by the fact that all valid services are included. And if a service is not in this list, it is no longer valid. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH v3 0/4] Implement ServicesAdded and ServicesRemoved
Hi, On Sat, 2012-02-25 at 18:02 +0100, Daniel Wagner wrote: > the ServicesAdded array does not containn 'old' servces. According the > documentation this array should contain all services in the right > order. That's a good point. First the document says: "...The array is a list of services that is sorted with existing services containing an empty dictionary and new services containing the properties." But then it says: "This signal will only inform about added services...", which after a third reading probably intends to refer to the difference of "added" vs. "removed" signals if the first part is to be true as well. Darn, this is rather confusing. Cheers, Patrik ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
