Re: [RFC 3/5] resolver: Create STATEDIR and use it when writing resolv.conf
Hi Patrik,
On pe, 2015-10-30 at 12:44 +0200, Patrik Flykt wrote:
> Create STATEDIR [/var]/run/connman and unconditionally write resolv.conf
> to this directory.
> ---
> src/main.c | 6 ++
> src/resolver.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/main.c b/src/main.c
> index e46fa7b..6cf6bc8 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -623,6 +623,12 @@ int main(int argc, char *argv[])
> perror("Failed to create storage directory");
> }
>
> + if (mkdir(STATEDIR, S_IRUSR | S_IWUSR | S_IXUSR |
> + S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH) < 0) {
> + if (errno != EEXIST)
> + perror("Failed to create storage directory");
> + }
> +
It might be better if the STATEDIR creation would be done in outside of
connman like by tmpfiles.d or similar. Then we could fallback to older
behaviour (== writing resolv.conf to /etc) if STATEDIR does not exist.
With the current code, the libc resolving might not work if user has not
managed to correctly setup /etc/resolv.conf to be link
into /var/run/connman/resolv.conf
> umask(0077);
>
> main_loop = g_main_loop_new(NULL, FALSE);
> diff --git a/src/resolver.c b/src/resolver.c
> index 6a64938..9db2756 100644
> --- a/src/resolver.c
> +++ b/src/resolver.c
> @@ -130,7 +130,7 @@ static int resolvfile_export(void)
>
> old_umask = umask(022);
>
> - fd = open("/etc/resolv.conf", O_RDWR | O_CREAT | O_CLOEXEC,
> + fd = open(STATEDIR"/resolv.conf", O_RDWR | O_CREAT | O_CLOEXEC,
> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> if (fd < 0) {
Here could fallback to older behavior and write to /etc if the new
directory does not exist.
> err = -errno;
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] IPv6 Timeserver for NTP
Hi Naveen,
On pe, 2015-10-02 at 10:20 -0700, Naveen Singh wrote:
> Hi Jukka,
>
> On Fri, Oct 2, 2015 at 12:29 AM, Jukka Rissanen
> wrote:
> Hi Naveen,
>
> On to, 2015-10-01 at 23:00 -0700, Naveen Singh wrote:
> > On Thu, Oct 1, 2015 at 6:26 AM, Patrik Flykt
>
> > wrote:
> >
> > >
> > > Hi,
> > >
> > > On Wed, 2015-09-30 at 22:08 -0700, Naveen Singh wrote:
> > > > From: Naveen Singh
> > > >
> > > > Current NTP code is written with an assumption that
> timeserver is
> > > > always an IPv4 address. If there is an IPv6 timeserver
> then the socket
> > > > operation would fail with error as Permission denied
> (13). This change in
> > > > ntp.c ensures that code works fine with both IPv4 and
> IPv6 address.
> > > > ---
> > > > src/ntp.c | 129
> > >
> --
> > > > 1 file changed, 101 insertions(+), 28 deletions(-)
> > >
> > > This was patch version 2, so the next one is version 3.
> Add the version
> > > to the Subject: line as [PATCH v3], this can be done with
> > > 'git ... --subject-prefix="PATCH v3" ...'.
> > >
> > > > diff --git a/src/ntp.c b/src/ntp.c
> > > > index 2c313a4..a55365d 100644
> > > > --- a/src/ntp.c
> > > > +++ b/src/ntp.c
> > > > @@ -18,7 +18,6 @@
> > > > * Foundation, Inc., 51 Franklin St, Fifth Floor,
> Boston, MA
> > > 02110-1301 USA
> > > > *
> > > > */
> > > > -
> > > > #ifdef HAVE_CONFIG_H
> > > > #include
> > > > #endif
> > > > @@ -34,6 +33,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include
> > > >
> > > > @@ -117,12 +117,12 @@ static struct timespec mtx_time;
> > > > static int transmit_fd = 0;
> > > >
> > > > static char *timeserver = NULL;
> > > > -static struct sockaddr_in timeserver_addr;
> > > > +static struct sockaddr_storage timeserver_addr;
> > > > static gint poll_id = 0;
> > > > static gint timeout_id = 0;
> > > > static guint retries = 0;
> > > >
> > > > -static void send_packet(int fd, const char *server,
> uint32_t timeout);
> > > > +static void send_packet(int fd, const char *server,
> uint32_t timeout,
> > > int family);
> > > >
> > > > static void next_server(void)
> > > > {
> > > > @@ -143,17 +143,21 @@ static gboolean
> send_timeout(gpointer user_data)
> > > > if (retries++ == NTP_SEND_RETRIES)
> > > > next_server();
> > > > else
> > > > - send_packet(transmit_fd, timeserver,
> timeout << 1);
> > > > + send_packet(transmit_fd, timeserver,
> timeout << 1,
> > > timeserver_addr.ss_family);
> > > >
> > > > return FALSE;
> > > > }
> > > >
> > > > -static void send_packet(int fd, const char *server,
> uint32_t timeout)
> > > > +static void send_packet(int fd, const char *server,
> uint32_t timeout,
> > > int family)
> > >
> > > Instead of supplying a char *server, why don't we give a
> struct
> > > sockaddr* instead? What's the purpose of carrying the
> server
> > > "name" (nah, the IP address as a string), if it is already
> resolved in
> > > the calling function? BTW, it is available as
> timeserver_addr, so do we
> > > really need any of this information here?
> > >
>
Re: [PATCH] IPv6 Timeserver for NTP
Hi Naveen,
On to, 2015-10-01 at 23:00 -0700, Naveen Singh wrote:
> On Thu, Oct 1, 2015 at 6:26 AM, Patrik Flykt
> wrote:
>
> >
> > Hi,
> >
> > On Wed, 2015-09-30 at 22:08 -0700, Naveen Singh wrote:
> > > From: Naveen Singh
> > >
> > > Current NTP code is written with an assumption that timeserver is
> > > always an IPv4 address. If there is an IPv6 timeserver then the socket
> > > operation would fail with error as Permission denied (13). This change in
> > > ntp.c ensures that code works fine with both IPv4 and IPv6 address.
> > > ---
> > > src/ntp.c | 129
> > --
> > > 1 file changed, 101 insertions(+), 28 deletions(-)
> >
> > This was patch version 2, so the next one is version 3. Add the version
> > to the Subject: line as [PATCH v3], this can be done with
> > 'git ... --subject-prefix="PATCH v3" ...'.
> >
> > > diff --git a/src/ntp.c b/src/ntp.c
> > > index 2c313a4..a55365d 100644
> > > --- a/src/ntp.c
> > > +++ b/src/ntp.c
> > > @@ -18,7 +18,6 @@
> > > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > > *
> > > */
> > > -
> > > #ifdef HAVE_CONFIG_H
> > > #include
> > > #endif
> > > @@ -34,6 +33,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > >
> > > @@ -117,12 +117,12 @@ static struct timespec mtx_time;
> > > static int transmit_fd = 0;
> > >
> > > static char *timeserver = NULL;
> > > -static struct sockaddr_in timeserver_addr;
> > > +static struct sockaddr_storage timeserver_addr;
> > > static gint poll_id = 0;
> > > static gint timeout_id = 0;
> > > static guint retries = 0;
> > >
> > > -static void send_packet(int fd, const char *server, uint32_t timeout);
> > > +static void send_packet(int fd, const char *server, uint32_t timeout,
> > int family);
> > >
> > > static void next_server(void)
> > > {
> > > @@ -143,17 +143,21 @@ static gboolean send_timeout(gpointer user_data)
> > > if (retries++ == NTP_SEND_RETRIES)
> > > next_server();
> > > else
> > > - send_packet(transmit_fd, timeserver, timeout << 1);
> > > + send_packet(transmit_fd, timeserver, timeout << 1,
> > timeserver_addr.ss_family);
> > >
> > > return FALSE;
> > > }
> > >
> > > -static void send_packet(int fd, const char *server, uint32_t timeout)
> > > +static void send_packet(int fd, const char *server, uint32_t timeout,
> > int family)
> >
> > Instead of supplying a char *server, why don't we give a struct
> > sockaddr* instead? What's the purpose of carrying the server
> > "name" (nah, the IP address as a string), if it is already resolved in
> > the calling function? BTW, it is available as timeserver_addr, so do we
> > really need any of this information here?
> >
>
> Yes it makes sense but I am not sure sockaddr * is the one we should us. It
> will not be able to hold IPv6 address which is 16 bytes. So I guess
> sockaddr_storage* would be the right thing. Do you agree? If you look i
> changed type of timeserver_addr to sockaddr_storage. Do you agree with this?
>
> /* Structure describing a generic socket address. */
> struct sockaddr
> {
> __SOCKADDR_COMMON (sa_);/* Common data: address family and length.
> */
> char sa_data[14]; /* Address data. */
> };
>
>
You should never instantiate (== have a variable "struct sockaddr
myaddr") because there is not enough space as you noticed. You either
have a "struct sockaddr_in myaddr" or "struct sockaddr_in6 myaddr" and
then you just cast "struct sockaddr *" to correct variable.
There is no need to use sockaddr_storage here.
>
> > > {
> > > struct ntp_msg msg;
> > > - struct sockaddr_in addr;
> > > + struct sockaddr_in in4addr;
> > > + struct sockaddr_in6 in6addr;
> > > + struct sockaddr * addr;
> > > struct timeval transmit_timeval;
> > > ssize_t len;
> > > + int size;
> > > + unsigned char * addrptr;
> > >
> > > /*
> > >* At some point, we could specify the actual system precision
> > with:
> > > @@ -168,10 +172,29 @@ static void send_packet(int fd, const char
> > *server, uint32_t timeout)
> > > msg.poll = 10; // max
> > > msg.precision = NTP_PRECISION_S;
> > >
> > > - memset(&addr, 0, sizeof(addr));
> > > - addr.sin_family = AF_INET;
> > > - addr.sin_port = htons(123);
> > > - addr.sin_addr.s_addr = inet_addr(server);
> > > + if (family == AF_INET) {
> > > + memset(&in4addr, 0, sizeof(in4addr));
> > > + in4addr.sin_family = AF_INET;
> > > + in4addr.sin_port = htons(123);
> > > + size = sizeof(in4addr);
> > > + addrptr = (unsigned char *)&in4addr.sin_addr.s_addr;
> > > + addr = (struct sockaddr *)&in4addr;
> > > + } else if (family == AF_INET6){
> > > + memset(&in6addr, 0, sizeof(in6addr));
> > > + in6addr.sin6_family = AF_INET6;
> >
Re: Connman
Hi Dmitriy, On pe, 2015-08-14 at 09:01 +, Klimenko, Dmitriy wrote: > Hello, > > I want to use connman in my project and I have a few questions regarding > connman usage. > > Is it possible to use connman as a librarary and not via DBus? > If yes, could you please send instruction? No, connman is only run as a daemon and controlled via dbus. > > Is there any connman interface to send raw data to the desirable network > interface controller(wifi, bt)? No, and what would be the point? ConnMan is connection manager, no data streams go via the daemon. Can't you just create a raw socket and write data directly to it. > > Thanks in advance. > Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/2] config: monitor inotify event IN_MOVED_FROM
Hi Jaakko, On ti, 2015-07-28 at 15:48 +0300, Jaakko Hannikainen wrote: > If a config file is moved from a config directory, IN_DELETE is not > fired but IN_MOVED_FROM is, so both have to be monitored. > --- > src/config.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/config.c b/src/config.c > index 5bf5cf1..41d3e3d 100644 > --- a/src/config.c > +++ b/src/config.c > @@ -925,7 +925,7 @@ static void config_notify_handler(struct inotify_event > *event, > } > } > > - if (event->mask & IN_DELETE) > + if (event->mask & IN_DELETE || event->mask & IN_MOVED_FROM) > g_hash_table_remove(config_table, ident); > } > Nice catch, ACK to both of these inotify patches. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v1 3/4] firewall: Add support for single rule add/remove operations
Hi Daniel,
On ti, 2015-07-28 at 08:57 +0200, Daniel Wagner wrote:
> We like to add and remove rules while the firewall is up and running.
> For example we need to insert per Session rule in the global
> NAT table. That could also be implemented destroying the whole table
> and recreate it when need but that is quite an overhead.
>
> Instead of taking down the whole table down we add an API to
> add and remove new rules during runtime.
> ---
> src/connman.h | 3 +
> src/firewall.c| 152
> ++
> tools/iptables-unit.c | 39 +++--
> 3 files changed, 152 insertions(+), 42 deletions(-)
>
> diff --git a/src/connman.h b/src/connman.h
> index 29151af..654b8fa 100644
> --- a/src/connman.h
> +++ b/src/connman.h
> @@ -989,6 +989,9 @@ int __connman_firewall_add_rule(struct firewall_context
> *ctx,
> const char *table,
> const char *chain,
> const char *rule_fmt, ...);
> +int __connman_firewall_remove_rule(struct firewall_context *ctx, int id);
> +int __connman_firewall_enable_rule(struct firewall_context *ctx, int id);
> +int __connman_firewall_disable_rule(struct firewall_context *ctx, int id);
> int __connman_firewall_enable(struct firewall_context *ctx);
> int __connman_firewall_disable(struct firewall_context *ctx);
> bool __connman_firewall_is_up(void);
> diff --git a/src/firewall.c b/src/firewall.c
> index 90c3d3c..8f14c44 100644
> --- a/src/firewall.c
> +++ b/src/firewall.c
> @@ -2,7 +2,7 @@
> *
> * Connection Manager
> *
> - * Copyright (C) 2013 BMW Car IT GmbH.
> + * Copyright (C) 2013,2015 BMW Car IT GmbH.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -31,6 +31,7 @@
> #include "connman.h"
>
> #define CHAIN_PREFIX "connman-"
> +#define FW_ALL_RULES -1
>
> static const char *builtin_chains[] = {
> [NF_IP_PRE_ROUTING] = "PREROUTING",
> @@ -46,6 +47,8 @@ struct connman_managed_table {
> };
>
> struct fw_rule {
> + int id;
> + bool enabled;
> char *table;
> char *chain;
> char *rule_spec;
> @@ -58,6 +61,7 @@ struct firewall_context {
> static GSList *managed_tables;
>
> static bool firewall_is_up;
> +static unsigned int firewall_rule_id;
>
> static int chain_to_index(const char *chain_name)
> {
> @@ -267,6 +271,51 @@ void __connman_firewall_destroy(struct firewall_context
> *ctx)
> g_free(ctx);
> }
>
> +static int firewall_enable_rule(struct fw_rule *rule)
> +{
> + int err;
> +
Should we check if the rule is already enabled here?
> + DBG("%s %s %s", rule->table, rule->chain, rule->rule_spec);
> +
> + err = insert_managed_rule(rule->table, rule->chain, rule->rule_spec);
> + if (err < 0)
> + return err;
> +
> + err = __connman_iptables_commit(rule->table);
> + if (err < 0)
> + return err;
> +
> + rule->enabled = true;
> +
> + return 0;
> +}
> +
> +static int firewall_disable_rule(struct fw_rule *rule)
> +{
> + int err;
> +
> + if (!rule->enabled)
> + return 0;
> +
> + err = delete_managed_rule(rule->table, rule->chain, rule->rule_spec);
> + if (err < 0) {
> + connman_error("Cannot remove previously installed "
> + "iptables rules: %s", strerror(-err));
> + return err;
> + }
> +
> + err = __connman_iptables_commit(rule->table);
> + if (err < 0) {
> + connman_error("Cannot remove previously installed "
> + "iptables rules: %s", strerror(-err));
> + return err;
> + }
> +
> + rule->enabled = false;
> +
> + return 0;
> +}
> +
> int __connman_firewall_add_rule(struct firewall_context *ctx,
> const char *table,
> const char *chain,
> @@ -284,80 +333,109 @@ int __connman_firewall_add_rule(struct
> firewall_context *ctx,
>
> rule = g_new0(struct fw_rule, 1);
>
> + rule->id = firewall_rule_id++;
> + rule->enabled = false;
> rule->table = g_strdup(table);
> rule->chain = g_strdup(chain);
> rule->rule_spec = rule_spec;
>
> ctx->rules = g_list_append(ctx->rules, rule);
> -
> - return 0;
> + return rule->id;
> }
>
> -static int firewall_disable(GList *rules)
> +int __connman_firewall_remove_rule(struct firewall_context *ctx, int id)
> {
> struct fw_rule *rule;
> GList *list;
> - int err;
> + int err = -ENOENT;
>
> - for (list = rules; list; list = g_list_previous(list)) {
> + for (list = g_list_last(ctx->rules); list;
> + list = g_list_previous(list)) {
> rule = list->data;
>
> - err = delete_managed_rule(rule->table,
> - rule->chain, rule->ru
Re: [PATCH] ntp: Fix print format for timeval and make debug output more informative
On ma, 2015-07-27 at 17:47 +0200, Peter Meerwald wrote:
> timeval has signed values
> ---
> src/ntp.c |7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/ntp.c b/src/ntp.c
> index abb2caa..2c313a4 100644
> --- a/src/ntp.c
> +++ b/src/ntp.c
> @@ -332,14 +332,14 @@ static void decode_msg(void *base, size_t len, struct
> timeval *tv,
> adj.tv_sec = (long) offset;
> adj.tv_usec = (offset - adj.tv_sec) * 100;
>
> - DBG("adjusting time");
> + DBG("adjusting time %ld seconds, %ld msecs", adj.tv_sec,
> adj.tv_usec);
>
> if (adjtime(&adj, &adj) < 0) {
> connman_error("Failed to adjust time");
> return;
> }
>
> - DBG("%lu seconds, %lu msecs", adj.tv_sec, adj.tv_usec);
> + DBG("remaining adjustment %ld seconds, %ld msecs", adj.tv_sec,
> adj.tv_usec);
> } else {
> struct timeval cur;
> double dtime;
> @@ -349,14 +349,13 @@ static void decode_msg(void *base, size_t len, struct
> timeval *tv,
> cur.tv_sec = (long) dtime;
> cur.tv_usec = (dtime - cur.tv_sec) * 100;
>
> - DBG("setting time");
> + DBG("setting time: %ld seconds, %ld msecs", cur.tv_sec,
> cur.tv_usec);
>
> if (settimeofday(&cur, NULL) < 0) {
> connman_error("Failed to set time");
> return;
> }
>
> - DBG("%lu seconds, %lu msecs", cur.tv_sec, cur.tv_usec);
> }
> }
>
ACK from me.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] dnsproxy: Fix spelling of refreshing in debug message
On ma, 2015-07-27 at 17:46 +0200, Peter Meerwald wrote:
> ---
> src/dnsproxy.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/dnsproxy.c b/src/dnsproxy.c
> index 3a369bc..a1eda55 100644
> --- a/src/dnsproxy.c
> +++ b/src/dnsproxy.c
> @@ -333,14 +333,14 @@ static void refresh_dns_entry(struct cache_entry
> *entry, char *name)
> }
>
> if (!entry->ipv4) {
> - DBG("Refresing A record for %s", name);
> + DBG("Refreshing A record for %s", name);
> g_resolv_lookup_hostname(ipv4_resolve, name,
> dummy_resolve_func, NULL);
> age = 4;
> }
>
> if (!entry->ipv6) {
> - DBG("Refresing record for %s", name);
> + DBG("Refreshing record for %s", name);
> g_resolv_lookup_hostname(ipv6_resolve, name,
> dummy_resolve_func, NULL);
> age = 4;
ACK from me.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gweb: Don't close socket twice when channel is unref'd
Hi Peter,
On ma, 2015-07-27 at 17:45 +0200, Peter Meerwald wrote:
> From: Peter Meerwald
>
> since g_io_channel_set_close_on_unref() is called on the channel, no need
> to close socket manually beforehand, this fixes
>
> (connmand:14087): GLib-WARNING **: Invalid file descriptor.
> ---
> gweb/gweb.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/gweb/gweb.c b/gweb/gweb.c
> index f6828cf..5f18a0e 100644
> --- a/gweb/gweb.c
> +++ b/gweb/gweb.c
> @@ -1075,7 +1075,6 @@ static int connect_session_transport(struct web_session
> *session)
> session->addr->ai_addrlen) < 0) {
> if (errno != EINPROGRESS) {
> debug(session->web, "connect() %s", strerror(errno));
> - close(sk);
> return -EIO;
> }
> }
Good catch, ACK to this.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v0 3/4] firewall: Add support for single rule add/remove operations
Hi Wagi,
On ma, 2015-07-27 at 14:47 +0200, Daniel Wagner wrote:
> We like to add and remove rules while the filewall is up and running.
filewall -> firewall
> For example we need to insert per Session rule in the global
> NAT table. That could also be implemented destroying the whole table
> and recreate it when need but that is quite an overhead.
>
> Instead of taking down the whole table down we add an API to
> add and remove new rules during runtime.
> ---
> src/connman.h | 3 ++
> src/firewall.c| 112
> +++---
> tools/iptables-unit.c | 39 +++---
> 3 files changed, 126 insertions(+), 28 deletions(-)
>
> diff --git a/src/connman.h b/src/connman.h
> index 29151af..654b8fa 100644
> --- a/src/connman.h
> +++ b/src/connman.h
> @@ -989,6 +989,9 @@ int __connman_firewall_add_rule(struct firewall_context
> *ctx,
> const char *table,
> const char *chain,
> const char *rule_fmt, ...);
> +int __connman_firewall_remove_rule(struct firewall_context *ctx, int id);
> +int __connman_firewall_enable_rule(struct firewall_context *ctx, int id);
> +int __connman_firewall_disable_rule(struct firewall_context *ctx, int id);
> int __connman_firewall_enable(struct firewall_context *ctx);
> int __connman_firewall_disable(struct firewall_context *ctx);
> bool __connman_firewall_is_up(void);
> diff --git a/src/firewall.c b/src/firewall.c
> index 90c3d3c..c25d086 100644
> --- a/src/firewall.c
> +++ b/src/firewall.c
> @@ -46,6 +46,7 @@ struct connman_managed_table {
> };
>
> struct fw_rule {
> + int id;
> char *table;
> char *chain;
> char *rule_spec;
> @@ -58,6 +59,7 @@ struct firewall_context {
> static GSList *managed_tables;
>
> static bool firewall_is_up;
> +static unsigned int firewall_rule_id;
>
> static int chain_to_index(const char *chain_name)
> {
> @@ -284,38 +286,109 @@ int __connman_firewall_add_rule(struct
> firewall_context *ctx,
>
> rule = g_new0(struct fw_rule, 1);
>
> + rule->id = firewall_rule_id++;
> rule->table = g_strdup(table);
> rule->chain = g_strdup(chain);
> rule->rule_spec = rule_spec;
>
> ctx->rules = g_list_append(ctx->rules, rule);
> + return rule->id;
> +}
> +
> +static int firewall_enable_rule(struct fw_rule *rule)
> +{
> + int err;
> +
> + DBG("%s %s %s", rule->table, rule->chain, rule->rule_spec);
> +
> + err = insert_managed_rule(rule->table, rule->chain, rule->rule_spec);
> + if (err < 0)
> + return err;
> +
> + return __connman_iptables_commit(rule->table);
> +}
> +
> +static int firewall_disable_rule(struct fw_rule *rule)
> +{
> + int err;
> +
> + err = delete_managed_rule(rule->table, rule->chain, rule->rule_spec);
> + if (err < 0) {
> + connman_error("Cannot remove previously installed "
> + "iptables rules: %s", strerror(-err));
> + return err;
> + }
> +
> + err = __connman_iptables_commit(rule->table);
> + if (err < 0) {
> + connman_error("Cannot remove previously installed "
> + "iptables rules: %s", strerror(-err));
> + return err;
> + }
>
> return 0;
> }
>
> +
> +int __connman_firewall_remove_rule(struct firewall_context *ctx, int id)
> +{
> + struct fw_rule *rule;
> + GList *list;
> +
> + for (list = ctx->rules; list; list = list->next) {
> + rule = list->data;
> + if (rule->id != id)
> + continue;
> +
> + ctx->rules = g_list_remove(ctx->rules, rule);
> + cleanup_fw_rule(rule);
> + return 0;
> + }
> +
> + return -ENOENT;
> +}
> +
> +int __connman_firewall_enable_rule(struct firewall_context *ctx, int id)
> +{
> + struct fw_rule *rule;
> + GList *list;
> +
> + for (list = ctx->rules; list; list = list->next) {
> + rule = list->data;
> + if (rule->id != id)
> + continue;
> +
> + return firewall_enable_rule(rule);
> + }
> +
> + return -ENOENT;
> +}
__connman_firewall_remove_rule() and __connman_firewall_enable_rule()
and __connman_firewall_disable_rule() are looking quite similar, perhaps
some refactoring could be done here?
> +
> +int __connman_firewall_disable_rule(struct firewall_context *ctx, int id)
> +{
> + struct fw_rule *rule;
> + GList *list;
> +
> + for (list = ctx->rules; list; list = list->next) {
> + rule = list->data;
> + if (rule->id != id)
> + continue;
> +
> + return firewall_disable_rule(rule);
> + }
> +
> + return -ENOENT;
> +}
> +
> static int firewall_disable(GList *rules)
> {
> struct fw_rule *rule;
> GList *list;
> - int err;
>
> for (list = rules; list; list = g_list_previous(list))
Re: [PATCH v0 1/4] session_policy_local: Set defaults when using policy file
Hi Wagi,
On ma, 2015-07-27 at 14:47 +0200, Daniel Wagner wrote:
> When the policy file doesn't define all values of the polcies
polcies -> policy
> some of the values are not properly initialized or set
> to sane defaults. Setting all values to defaults and then
> overwrite all or partially is what most people would expect.
> Let's do it this way.
> ---
> plugins/session_policy_local.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/plugins/session_policy_local.c b/plugins/session_policy_local.c
> index b2369bd..5b108d8 100644
> --- a/plugins/session_policy_local.c
> +++ b/plugins/session_policy_local.c
> @@ -623,7 +623,7 @@ static int load_file(const char *filename, struct
> policy_file *file)
>
> for (i = 0; groupnames[i]; i++) {
> group = g_new0(struct policy_group, 1);
> - group->config = g_new0(struct connman_session_config, 1);
> + group->config = connman_session_create_default_config();
>
> err = load_policy(keyfile, groupnames[i], group);
> if (err < 0) {
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Update service documentation about Immutable
Hi Jaakko, On pe, 2015-07-24 at 12:54 +0300, Jaakko Hannikainen wrote: > If a service is set as Immutable, the AutoConnect property can still > be changed. > --- > doc/service-api.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/doc/service-api.txt b/doc/service-api.txt > index b4f1dca..88816d8 100644 > --- a/doc/service-api.txt > +++ b/doc/service-api.txt > @@ -215,9 +215,9 @@ Propertiesstring State [readonly] > This value will be set to true if the service is > configured externally via a configuration file. > > - The only valid operation are Connect() and of > - course Disconnect(). The Remove() method will > - result in an error. > + The only valid operations are Connect(), Disconnect() > + and changing the AutoConnect property. The Remove() > + method will result in an error. > > boolean AutoConnect [readwrite] > ACK from me. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] vpn: Fix NULL dereferencing in vpn_set_state
Hi Jaakko,
On ma, 2015-07-27 at 15:32 +0300, Jaakko Hannikainen wrote:
> Data might be NULL if called from vpn_died, so check it and do
> nothing if it is NULL.
> ---
> vpn/plugins/vpn.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/vpn/plugins/vpn.c b/vpn/plugins/vpn.c
> index 60954be..1b5af6e 100644
> --- a/vpn/plugins/vpn.c
> +++ b/vpn/plugins/vpn.c
> @@ -199,6 +199,8 @@ static int vpn_set_state(struct vpn_provider *provider,
> enum vpn_provider_state state)
> {
> struct vpn_data *data = vpn_provider_get_data(provider);
> + if (!data)
> + return -EINVAL;
>
> switch (state) {
> case VPN_PROVIDER_STATE_UNKNOWN:
Good catch, ACK to this.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] doc: Clarify the VPN routes description for IPv6
For VPN UserRoutes and ServerRoutes properties, the Netmask field is the IPv4 netmask (like 255.255.255.0) for IPv4 routes. For IPv6 routes it is the prefix length (like 64) instead. Reported by Jaakko Hannikainen. --- doc/vpn-connection-api.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/vpn-connection-api.txt b/doc/vpn-connection-api.txt index 4367699..a814a38 100644 --- a/doc/vpn-connection-api.txt +++ b/doc/vpn-connection-api.txt @@ -144,7 +144,8 @@ Properties string State [readonly] string Netmask - The netmask of the route. + The netmask of the route. For IPv6 routes, + this is the prefix length. string Gateway @@ -166,7 +167,8 @@ Properties string State [readonly] string Netmask - The netmask of the route. + The netmask of the route. For IPv6 routes, + this is the prefix length. string Gateway -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Seeing issues with NTP
Hi Naveen, On ti, 2015-07-21 at 18:16 -0700, Naveen Singh wrote: > Hi All > In our testing of new connman (version 1.29) we do see following error > print sometimes (This is happening very rarely and I do not have any easy > way to reproduce it at will): > > "2015-07-17 01:35:20.00 daemon.err connmand[321]: Invalid packet > timestamp from time server" > > After this print we see that we are not able to communicate to connman at > all. All the DBUS messages to connman are timing out. The only way to > recover from this situation is to restart the connman. > > Looking into the code in ntp.c, this piece of code looks completely benign > and I am not able to correlate this print with the failure that I see. But > in all the three instances (over last one month) whenever we see this > print. we find that connman is completely unresponsive. > > Has anyone else seen similar problem? > > Regards > Naveen I have not seen this error. After looking the relevant code it is hard to understand why ConnMan would become unresponsive because of this error print. Do you have more detailed debug log when the issue happens? It is probably some other issue that is actually causing the hang so a full debug log could be helpful here. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 6/6] vpn: Provider state was not updated after an error
This fixes following scenario:
- user tries to connect to a VPN
- VPN requests some additional data via agent interface
- user cancels the agent request
- VPN connection is terminated
- VPN service goes back to idle
- user tries to connect to a VPN again
- VPN does not ask anything from the user (this is the issue)
- user cannot connect to VPN
The reason for the problem was that the VPN plugin state
was not updated properly if the VPN connection attempt failed.
Reported by Jaakko Hannikainen.
---
vpn/plugins/vpn.c | 27 +++
vpn/vpn-provider.c | 3 +++
vpn/vpn-provider.h | 2 ++
3 files changed, 32 insertions(+)
diff --git a/vpn/plugins/vpn.c b/vpn/plugins/vpn.c
index b438d06..60954be 100644
--- a/vpn/plugins/vpn.c
+++ b/vpn/plugins/vpn.c
@@ -195,6 +195,32 @@ int vpn_set_ifname(struct vpn_provider *provider, const
char *ifname)
return 0;
}
+static int vpn_set_state(struct vpn_provider *provider,
+ enum vpn_provider_state state)
+{
+ struct vpn_data *data = vpn_provider_get_data(provider);
+
+ switch (state) {
+ case VPN_PROVIDER_STATE_UNKNOWN:
+ return -EINVAL;
+ case VPN_PROVIDER_STATE_IDLE:
+ data->state = VPN_STATE_IDLE;
+ break;
+ case VPN_PROVIDER_STATE_CONNECT:
+ case VPN_PROVIDER_STATE_READY:
+ data->state = VPN_STATE_CONNECT;
+ break;
+ case VPN_PROVIDER_STATE_DISCONNECT:
+ data->state = VPN_STATE_DISCONNECT;
+ break;
+ case VPN_PROVIDER_STATE_FAILURE:
+ data->state = VPN_STATE_FAILURE;
+ break;
+ }
+
+ return 0;
+}
+
static void vpn_newlink(unsigned flags, unsigned change, void *user_data)
{
struct vpn_provider *provider = user_data;
@@ -572,6 +598,7 @@ int vpn_register(const char *name, struct vpn_driver
*vpn_driver,
data->provider_driver.probe = vpn_probe;
data->provider_driver.remove = vpn_remove;
data->provider_driver.save = vpn_save;
+ data->provider_driver.set_state = vpn_set_state;
if (!driver_hash)
driver_hash = g_hash_table_new_full(g_str_hash,
diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
index a8d05bf..afd7ca6 100644
--- a/vpn/vpn-provider.c
+++ b/vpn/vpn-provider.c
@@ -1587,6 +1587,9 @@ int vpn_provider_indicate_error(struct vpn_provider
*provider,
break;
}
+ if (provider->driver && provider->driver->set_state)
+ provider->driver->set_state(provider, provider->state);
+
return 0;
}
diff --git a/vpn/vpn-provider.h b/vpn/vpn-provider.h
index 8105d7f..bdc5f5c 100644
--- a/vpn/vpn-provider.h
+++ b/vpn/vpn-provider.h
@@ -132,6 +132,8 @@ struct vpn_provider_driver {
void *user_data);
int (*disconnect) (struct vpn_provider *provider);
int (*save) (struct vpn_provider *provider, GKeyFile *keyfile);
+ int (*set_state)(struct vpn_provider *provider,
+ enum vpn_provider_state state);
};
int vpn_provider_driver_register(struct vpn_provider_driver *driver);
--
2.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 5/6] vpn: Set disconnected VPN service to IDLE
Setting the state of the disconnected VPN service to IDLE instead of leaving it to DISCONNECTED. Now it behaves the same way as the service that is disconnected by ConnMan daemon. Reported by Jaakko Hannikainen. --- src/provider.c | 4 1 file changed, 4 insertions(+) diff --git a/src/provider.c b/src/provider.c index d5ce825..0726f4a 100644 --- a/src/provider.c +++ b/src/provider.c @@ -148,6 +148,10 @@ int connman_provider_disconnect(struct connman_provider *provider) return -EINPROGRESS; } + if (provider->vpn_service) + provider_indicate_state(provider, + CONNMAN_SERVICE_STATE_IDLE); + return 0; } -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 4/6] vpn: Pass original sender to connman-vpnd when connecting
We need to give the original DBus sender to connman-vpnd
when connmand is proxying the connect request. Otherwise
the possible agent request goes to default vpn agent
instead of the correct agent that initiated the connect
request.
Reported by Jaakko Hannikainen.
---
include/provider.h | 3 ++-
plugins/vpn.c | 37 +
src/connman.h | 3 ++-
src/provider.c | 5 +++--
src/service.c | 3 ++-
vpn/vpn-provider.c | 25 +++--
6 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/include/provider.h b/include/provider.h
index d1a8983..d28651a 100644
--- a/include/provider.h
+++ b/include/provider.h
@@ -124,7 +124,8 @@ struct connman_provider_driver {
enum connman_provider_type type;
int (*probe) (struct connman_provider *provider);
int (*remove) (struct connman_provider *provider);
- int (*connect) (struct connman_provider *provider);
+ int (*connect) (struct connman_provider *provider,
+ const char *dbus_sender);
int (*disconnect) (struct connman_provider *provider);
int (*save) (struct connman_provider *provider, GKeyFile *keyfile);
int (*set_property) (struct connman_provider *provider,
diff --git a/plugins/vpn.c b/plugins/vpn.c
index e6e4c8e..7202734 100644
--- a/plugins/vpn.c
+++ b/plugins/vpn.c
@@ -512,26 +512,39 @@ done:
dbus_pending_call_unref(call);
}
-static int connect_provider(struct connection_data *data, void *user_data)
+static int connect_provider(struct connection_data *data, void *user_data,
+ const char *dbus_sender)
{
DBusPendingCall *call;
DBusMessage *message;
struct config_create_data *cb_data = user_data;
- DBG("data %p user %p path %s", data, cb_data, data->path);
+ DBG("data %p user %p path %s sender %s", data, cb_data, data->path,
+ dbus_sender);
data->connect_pending = false;
+#define VPN_CONNECT2 "Connect2"
+
+ /* We need to pass original dbus sender to connman-vpnd,
+* use a Connect2 method for that.
+*/
message = dbus_message_new_method_call(VPN_SERVICE, data->path,
VPN_CONNECTION_INTERFACE,
- VPN_CONNECT);
+ VPN_CONNECT2);
if (!message)
return -ENOMEM;
+ if (dbus_sender)
+ dbus_message_append_args(message, DBUS_TYPE_STRING,
+ &dbus_sender, NULL);
+ else
+ dbus_sender = "";
+
if (!dbus_connection_send_with_reply(connection, message,
&call, DBUS_TIMEOUT)) {
connman_error("Unable to call %s.%s()",
- VPN_CONNECTION_INTERFACE, VPN_CONNECT);
+ VPN_CONNECTION_INTERFACE, VPN_CONNECT2);
dbus_message_unref(message);
return -EINVAL;
}
@@ -658,8 +671,15 @@ static void add_connection(const char *path,
DBusMessageIter *properties,
connman_provider_set_domain(data->provider,
data->domain);
- if (data->connect_pending)
- connect_provider(data, data->cb_data);
+ if (data->connect_pending) {
+ const char *dbus_sender = NULL;
+
+ if (data->cb_data && data->cb_data->message) {
+ dbus_sender =
+ dbus_message_get_sender(data->cb_data->message);
+ }
+ connect_provider(data, data->cb_data, dbus_sender);
+ }
return;
@@ -857,7 +877,8 @@ static int provider_remove(struct connman_provider
*provider)
return 0;
}
-static int provider_connect(struct connman_provider *provider)
+static int provider_connect(struct connman_provider *provider,
+ const char *dbus_sender)
{
struct connection_data *data;
@@ -865,7 +886,7 @@ static int provider_connect(struct connman_provider
*provider)
if (!data)
return -EINVAL;
- return connect_provider(data, NULL);
+ return connect_provider(data, NULL, dbus_sender);
}
static void disconnect_reply(DBusPendingCall *call, void *user_data)
diff --git a/src/connman.h b/src/connman.h
index aac6a0b..29151af 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -642,7 +642,8 @@ int __connman_provider_indicate_state(struct
connman_provider *provider,
enum connman_provider_state state);
int __connman_provider_indicate_error(struct connman_provider *provider,
enum connman_provider_error error);
-int __connman_provider_connect(struct connman_provider *provider);
+int __connman_provider_connect(
[PATCH 1/6] agent: Do not access NULL pointer in cancelling
If agent API user (in this case connman-vpnd) has not set
the memory allocation callback (context_ref pointer), then
the requst->driver pointer will be NULL and we will get
a segfault in this usage scenario:
$ connmanctl
connmanctl> vpnagent on
connmanctl> connect vpn_service
VPN Agent RequestInput vpn_service
OpenConnect Cookie? CTRL-c
Reported by Jaakko Hannikainen.
---
src/agent.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/agent.c b/src/agent.c
index bdeb0e7..d26d8dc 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -165,12 +165,17 @@ static int send_cancel_request(struct connman_agent
*agent,
struct connman_agent_request *request)
{
DBusMessage *message;
+ const char *interface = NULL;
- DBG("send cancel req to %s %s", agent->owner, agent->path);
+ if (request && request->driver)
+ interface = request->driver->interface;
+
+ DBG("send cancel req to %s %s iface %s", agent->owner, agent->path,
+ interface);
message = dbus_message_new_method_call(agent->owner,
agent->path,
- request->driver->interface,
+ interface,
"Cancel");
if (!message) {
connman_error("Couldn't allocate D-Bus message");
--
2.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 3/6] vpn: Clear any pending DNS resolver query when quitting
This is a special case that happens if we for example stop ConnMan while there is a pending DNS resolver going on. Fixing this minor memory leak helps to catch the more serious leaks in ConnMan. Reported by Jaakko Hannikainen. --- vpn/vpn-provider.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c index 16c0c2b..b0aadcd 100644 --- a/vpn/vpn-provider.c +++ b/vpn/vpn-provider.c @@ -549,6 +549,12 @@ static void resolv_result(GResolvResultStatus status, provider->host_ip = g_strdupv(results); vpn_provider_unref(provider); + + /* Remove the resolver here so that it will not be left +* hanging around and cause double free in unregister_provider() +*/ + g_resolv_unref(provider->resolv); + provider->resolv = NULL; } static void provider_resolv_host_addr(struct vpn_provider *provider) @@ -1605,6 +1611,18 @@ static void unregister_provider(gpointer data) connection_unregister(provider); + /* If the provider has any DNS resolver queries pending, +* they need to be cleared here because the unref will not +* be able to do that (because the provider_resolv_host_addr() +* has increased the ref count by 1). This is quite rare as +* normally the resolving either returns a value or has a +* timeout which clears the memory. Typically resolv_result() will +* unref the provider but in this case that call has not yet +* happened. +*/ + if (provider->resolv) + vpn_provider_unref(provider); + vpn_provider_unref(provider); } -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/6] vpn: NULL dbus message in plugin input handler
If the user cancelled the agent request, then we might
have NULL reply in the input handler. If we try to pass
this kind of reply to dbus library, it will normally
just abort. So catch this and do not pass NULL message
to dbus_message_get_type().
This affects openconnect, l2tp and pptp input handlers.
---
vpn/plugins/l2tp.c| 5 +++--
vpn/plugins/openconnect.c | 2 +-
vpn/plugins/pptp.c| 5 +++--
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/vpn/plugins/l2tp.c b/vpn/plugins/l2tp.c
index 22f9dcf..372e2ed 100644
--- a/vpn/plugins/l2tp.c
+++ b/vpn/plugins/l2tp.c
@@ -497,8 +497,9 @@ static void request_input_reply(DBusMessage *reply, void
*user_data)
DBG("provider %p", l2tp_reply->provider);
- if (dbus_message_get_type(reply) == DBUS_MESSAGE_TYPE_ERROR) {
- error = dbus_message_get_error_name(reply);
+ if (!reply || dbus_message_get_type(reply) == DBUS_MESSAGE_TYPE_ERROR) {
+ if (reply)
+ error = dbus_message_get_error_name(reply);
goto done;
}
diff --git a/vpn/plugins/openconnect.c b/vpn/plugins/openconnect.c
index 5feaed9..87679bf 100644
--- a/vpn/plugins/openconnect.c
+++ b/vpn/plugins/openconnect.c
@@ -315,7 +315,7 @@ static void request_input_cookie_reply(DBusMessage *reply,
void *user_data)
DBG("provider %p", data->provider);
- if (dbus_message_get_type(reply) == DBUS_MESSAGE_TYPE_ERROR)
+ if (!reply || dbus_message_get_type(reply) == DBUS_MESSAGE_TYPE_ERROR)
goto err;
if (!vpn_agent_check_reply_has_dict(reply))
diff --git a/vpn/plugins/pptp.c b/vpn/plugins/pptp.c
index 9f2a214..90fd24c 100644
--- a/vpn/plugins/pptp.c
+++ b/vpn/plugins/pptp.c
@@ -289,8 +289,9 @@ static void request_input_reply(DBusMessage *reply, void
*user_data)
DBG("provider %p", pptp_reply->provider);
- if (dbus_message_get_type(reply) == DBUS_MESSAGE_TYPE_ERROR) {
- error = dbus_message_get_error_name(reply);
+ if (!reply || dbus_message_get_type(reply) == DBUS_MESSAGE_TYPE_ERROR) {
+ if (reply)
+ error = dbus_message_get_error_name(reply);
goto done;
}
--
2.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 0/6] VPN fixes
Hi, these patches fix multiple issues in VPN connectivity. Thanks to Jaakko Hannikainen for finding these issues. Patch 1 fixes a crash issue in connman-vpnd. User is able to cause segfault via connmanctl. Another serious issue is found in patch 2 where dbus library will abort if given invalid parameters. A minor memory leak is fixed by patch 3. It is only seen if one quits ConnMan while there is a DNS request pending. If there are multiple agents registered in the system, then the agent request generated by connman-vpnd might go to default agent even if the connection request came from a properly registered agent. Fixed in patch 4. VPN service was left in disconnected state if user manually disconnected it. This behaves now same way as if ConnMan was disconnecting the VPN service. The VPN service state is set to idle in patch 5. If user connects to a VPN service but cancels the connection request after agent has asked something from the user, then it is possible that subsequent connection attemps will not ask user. This is fixed in patch 6. Cheers, Jukka Jukka Rissanen (6): agent: Do not access NULL pointer in cancelling vpn: NULL dbus message in plugin input handler vpn: Clear any pending DNS resolver query when quitting vpn: Pass original sender to connman-vpnd when connecting vpn: Set disconnected VPN service to IDLE vpn: Provider state was not updated after an error include/provider.h| 3 ++- plugins/vpn.c | 37 + src/agent.c | 9 +++-- src/connman.h | 3 ++- src/provider.c| 9 +++-- src/service.c | 3 ++- vpn/plugins/l2tp.c| 5 +++-- vpn/plugins/openconnect.c | 2 +- vpn/plugins/pptp.c| 5 +++-- vpn/plugins/vpn.c | 27 +++ vpn/vpn-provider.c| 46 -- vpn/vpn-provider.h| 2 ++ 12 files changed, 129 insertions(+), 22 deletions(-) -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc/technology-api.txt: Fix typo
Hi Marko, On ke, 2015-07-15 at 15:03 +0200, Marko Sulejic wrote: > --- > doc/technology-api.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/technology-api.txt b/doc/technology-api.txt > index f97eac0..f3703c0 100644 > --- a/doc/technology-api.txt > +++ b/doc/technology-api.txt > @@ -56,7 +56,7 @@ Properties boolean Powered [readwrite] > > Boolean representing if a technology is connected. > > - This is just a convience property for allowing the > + This is just a convenience property for allowing the > UI to easily show if this technology has an active > connection or not. > patch has been applied, thanks! Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2 0/6] Strip whitespace and empty strings from DBus input
Hi Jaakko, On ke, 2015-07-15 at 15:26 +0300, Jaakko Hannikainen wrote: > Hello, > > These patches remove empty strings and leading/trailing whitespace from DBus > > input for Domains.Configuration, Proxy.Configuration, > Timeservers.Configuration > and Nameservers.Configuration. > > > > Previously, Nameservers.Configuration accepted invalid values such as > > "192.0.2.1 invalid-ip 8.8.8.8 " and then split them with space as delimiter, > > resulting in Nameservers.Configuration containing > > [192.0.2.1, , invalid-ip, 8.8.8.8, ] rather than the valid value > > [192.0.2.1, 8.8.8.8]. > > > > The v2 implements remove_empty_strings much more sensibly, fixes some style > > issues and adds a patch for Nameservers.Configuration. > > Managed to fudge the cover letter first time around, sorry. > > Jaakko Hannikainen (6): > service: Add function to remove empty strings > service: Remove empty strings from Domains > service: Remove empty strings from Proxy > service: Strip whitespace from Proxy URL > service: Remove empty strings from Timeservers > service: Remove empty strings from Nameservers > > src/service.c | 109 > +++--- > 1 file changed, 74 insertions(+), 35 deletions(-) > All patches have been applied, thanks! Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: cellular technology is not getting listed
Hi Ram, On to, 2015-07-16 at 08:24 +, Kallumari Nagaraja Rao, RammohanX wrote: > All, > > Following things are done, > > 1./var/lib/connman cellular added What do you mean by this? > > 2./etc/connman/main.conf has wifi and cellular as preferred technologies PreferredTechnologies only affects how ConnMan does autoconnect. > > 3.connmand is running I assume you have ofono plugin compiled and used by ConnMan? Are you using Yocto based distro or have you compiled ConnMan yourself? > > 4.ofonod running > > 5.cellular context was created after enabling the he910 modem So ofono shows the cellular context correctly if you invoke list-contexts script from ofono, is it so? Do you have APN and PIN correctly setup? > > 6.ifconfig list ppp0 What does the above command show? > > however, connmanctl does not list the cellular technology. So the cellular technology is not shown which indicates that ConnMan does not know anything about the modem. If the cellular service is not shown (but technology is), then the cellular context is not properly setup. What ConnMan version are you using? > > After doing ifconfig, ppp0 does not have inet addr listed. > > Please let me know if there is something missing. > > Regards, > Ram. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2 0/6] Strip whitespace and empty strings from DBus input
Hi Jaakko, On ke, 2015-07-15 at 15:26 +0300, Jaakko Hannikainen wrote: > Hello, > > These patches remove empty strings and leading/trailing whitespace from DBus > > input for Domains.Configuration, Proxy.Configuration, > Timeservers.Configuration > and Nameservers.Configuration. > > > > Previously, Nameservers.Configuration accepted invalid values such as > > "192.0.2.1 invalid-ip 8.8.8.8 " and then split them with space as delimiter, > > resulting in Nameservers.Configuration containing > > [192.0.2.1, , invalid-ip, 8.8.8.8, ] rather than the valid value > > [192.0.2.1, 8.8.8.8]. > > > > The v2 implements remove_empty_strings much more sensibly, fixes some style > > issues and adds a patch for Nameservers.Configuration. > > Managed to fudge the cover letter first time around, sorry. looks good so ACK from me. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 3/5] service: Remove empty strings from Proxy
Hi Jaakko,
On ke, 2015-07-15 at 11:35 +0300, Jaakko Hannikainen wrote:
> Same as previous commit, but for Proxy.Configuration.
Proper commit message please.
> ---
> src/service.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index 37f8fb9..2bf64e8 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -3071,9 +3071,12 @@ static int update_proxy_configuration(struct
> connman_service *service,
> if (servers_str) {
> g_strfreev(service->proxies);
>
> - if (servers_str->len > 0)
> - service->proxies = g_strsplit_set(
> + if (servers_str->len > 0) {
> + char **proxies = g_strsplit_set(
> servers_str->str, " ", 0);
> + proxies = remove_empty_strings(proxies);
> + service->proxies = proxies;
> + }
> else
> service->proxies = NULL;
> }
> @@ -3081,9 +3084,12 @@ static int update_proxy_configuration(struct
> connman_service *service,
> if (excludes_str) {
> g_strfreev(service->excludes);
>
> - if (excludes_str->len > 0)
> - service->excludes = g_strsplit_set(
> + if (excludes_str->len > 0) {
> + char **excludes = g_strsplit_set(
> excludes_str->str, " ", 0);
> + excludes = remove_empty_strings(excludes);
> + service->excludes = excludes;
> + }
> else
> service->excludes = NULL;
> }
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/5] service: Add function to remove empty strings
Hi Jaakko,
On ke, 2015-07-15 at 11:35 +0300, Jaakko Hannikainen wrote:
> This helper function takes in a heap-allocated buffer of heap-allocated
> strings. If no strings should be removed, return the buffer. Else, free
> all empty strings, place nonempty strings to a new container and return
> it, freeing the old container.
> ---
> src/service.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/src/service.c b/src/service.c
> index 2d8245e..1723586 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -2926,6 +2926,38 @@ static DBusMessage *get_properties(DBusConnection
> *conn,
> return reply;
> }
>
> +static char **remove_empty_strings(char **strv)
> +{
> + int amount, length, index;
> + char **iter, **out;
> +
> + amount = 0;
> + length = g_strv_length(strv);
We could remove the call to g_strv_length() and calculate the max length
in the while loop below.
> + iter = strv;
> +
> + while (*iter)
> + if (strlen(*iter++))
> + amount++;
> +
> + if (amount == length - 1)
> + return strv;
> +
> + out = g_new0(char *, amount+1);
> + index = 0;
> + iter = strv;
> +
> + while (*iter) {
> + if (strlen(*iter))
> + out[index++] = *iter;
> + else
> + g_free(*iter);
> + iter++;
> + }
> +
> + g_free(strv);
> + return out;
> +}
> +
> static int update_proxy_configuration(struct connman_service *service,
> DBusMessageIter *array)
> {
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
On to, 2015-07-09 at 11:15 +0200, Marcel Holtmann wrote: > Hi Jussi, > > >>> Now that we're talking about the online check... I've talked to people > >>> who considered this behaviour "calling home" and thought it > >>> unreasonable that > >>> a) it's not possible to prevent the online check from happening via > >>> configuration and > >> > >> > >> Why would you prevent it to happen? This check is something extra anyway, > >> being "ready" means you are connected. In a way, people should not care too > >> much not seeing there service being set to "online", since such check > >> can't > >> be bullet-proof. > > > > It's not about connman functionality at all. It's (as an example) > > about people building a super secret embedded product demo on top of > > Yocto suddenly realizing that their device is connecting to a web > > server they don't control or even know about (aka "who is this Marcel > > Holtmann why is our IOT Fridge fetching web pages from him?") > > if this super secret fridge is connected to the Internet and can actually > reach it, then it is no longer super secret. If you would be really worried, > then you would have it locked up in a lab with no access to anything. > > And even if it would be calling the ConnMan servers, nobody in the world > could tell super secret fridge apart from someone sitting next to it using > ConnMan on Yocto on a Minnowboard or its laptop. > > I can not repeat this enough. This whole think is designed with full > anonymity in mind. We are building our own HTTP request for exactly that > reason. No headers can sneak in. No unwanted meta data can leak. ConnMan > ships its own HTTP client for a reason. > > Think about this for a second. You can leak more information by using a > distro libcurl by accident that includes some meta headers. If ConnMan's > online check is your concern, then you do not understand privacy at all. > > > FWIW, I totally understand the point Patrik makes in the previous > > discussion: > >> If the URL is configurable, upstream > >> does not have the means to fix online related bug reports as we'd be > >> unable to confirm the online checking service to work properly in the > >> first place. In the worst case even the URL accessed is not known, not > >> even to the person submitting the bug report. > > > > This is a compelling argument as well -- I'm not in favor of making > > this too easy. I do think there are legitimate use cases where people > > do not want to rely on Marcel (or Intel) handling their online checks. > > > > Since the required patches are not big (as shown by Pasi, thanks!) > > just adding clear documentation to Yocto about the online check > > Connman makes and instructions on how to modify it may be a sufficient > > alternative. > > If someone wants to add documentation on what ConnMan is doing, then I am all > for it. More documentation is always good. I am in favor of full transparency. There is already documentation about online check in ConnMan README file. If that is not enough, then patches are welcome. > > I am however not in favor of giving such an option. If someone wants to shoot > themselves into the foot, then they can pick up the gun by themselves. I do > not see a good reason why would make this easy. > > And honestly I prefer them carrying an extra patch changing the defines in > the source code. That means they have to carry that extra patch. So every > time it breaks, they get a nice reminder that something might have changed. > So they have a change in catching it. The config file is to easy to forget. > > Regards > > Marcel Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Not able to start dbus in ARM platform
On ma, 2015-06-08 at 15:24 +0300, Patrik Flykt wrote: > On Mon, 2015-06-08 at 17:38 +0530, Sukanya Ch wrote: > > Hi, > > > > I am using connman in ARM platform. But while starting daemon I am getting > > this error. Can you please help me? > > There are no errors below. ConnMan is just a little bit too eager with > its DNS when starting up. Nothing to worry about at this time in the > bootup process. It is also possible that you have some other DNS proxy running in your host. In this case ConnMan cannot start its dnsproxy as that would use the same UDP port. Cheers, Jukka > > Cheers, > > Patrik > > > connmand_logs: > > - > > connmand[10454]: src/dnsproxy.c:__connman_dnsproxy_init() > > connmand[10454]: src/dnsproxy.c:__connman_dnsproxy_add_listener() index 1 > > connmand[10454]: src/dnsproxy.c:get_listener() family 2 protocol 17 index 1 > > connmand[10454]: src/inet.c:__connman_inet_get_interface_address() index 1 > > interface lo > > connmand[10454]: Failed to bind UDP listener socket > > connmand[10454]: src/dnsproxy.c:get_listener() family 10 protocol 17 index 1 > > connmand[10454]: src/inet.c:__connman_inet_get_interface_address() index 1 > > interface lo > > connmand[10454]: Failed to bind UDP listener socket > > connmand[10454]: Couldn't create listener for index 1 err -5 > > connmand[10454]: src/ipconfig.c:__connman_ipconfig_init() > > connmand[10454]: src/rtnl.c:__connman_rtnl_init() > > connmand[10454]: src/task.c:__connman_task_init() > > > ___ > 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
Re: Connman cancel request?
Hi Ronney, On pe, 2015-05-22 at 14:02 +0200, ronney.kai...@europe.svpworldwide.com wrote: > Hello! > > Is there any way of cancel or abort a connect request to connman? Or do I > have to wait for the request to timeout? Have you tried to disconnect a connecting service? So if you have a connect pending to service xyz, you could try to disconnect it like this "connmanctl disconnect service_xyz" Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Disable rp_filter in main.conf
Hi Urs, On ti, 2015-05-12 at 09:34 +, Urs Ritzmann wrote: > Hi connman devs, > > We're running connman on a system using PTP (IEEE1588). The problem is that > connman is fiddling with the rp_filter settings and activating loose mode > routing (value 2) if two or more services are present. We cannot have > ip_filter activated because it blocks certain PTP frames. According to this I > have two questions: > > > 1) I currently do not understand the following: Rp_filter is just a > recommended security practice (RFC3704). But the connman commit message > sounds like rp_filter is needed to ensure proper functionality with two or > more interfaces. > > commit cb3e78500a2539a61d73ecb9708a2b06ea1f356d > Author: Jukka Rissanen > mailto:jukka.rissa...@linux.intel.com>> > Date: Fri Oct 21 11:16:55 2011 +0300 > > service: Activate loose mode routing > > If more than one service is connected at the same time, > then activate loose mode routing by setting the > /proc/sys/net/ipv4/conf/all/rp_filter to value 2 > If the loose mode routing is not activated, then packets > are not routed properly if services are connected to same > subnet. > > The original value of rp_filter is restored when the other > services are disconnected and only one service is connected. > > For details of rp_filter setting, see Linux kernel file > Documentation/networking/ip-sysctl.txt > > Fixes BMC#23606 > > What means "not routed properly"? Can we run into any problems when disabling > rp_filter but having multiple interfaces/services (e.g. Ethernet and WiFi)? > Is the actual reason that connman sets rp_filter because of security or are > there any other reasons? See these two bug reports for details for this change: https://01.org/jira/browse/CM-360 https://01.org/jira/browse/CM-375 > > 2) What is your opinion about a submitting patch which introduces a config > option to never change rp_filter settings? Are there good changes to have > this integrated in the main sources. > > Thanks, > Urs > > Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Multiple connections?
Hi Daniel, On ke, 2015-05-06 at 16:36 +0200, Daniel Nyström wrote: > Hi ConnMan folks! > > I've just started using ConnMan and figured my situation is a bit > different than most of you. > > I've got a GSM module (SIM800h) run by oFono connected to ConnMan. I > also got a LAN connection with DHCP. > > I need both of these connections to be available, but of course only > one can be the primary interface (hence the one with a default > gateway). We can say the cellular connection always has this role if > available. > > How can I make this using ConnMan? How can I make the DHCP ignore the > default gw? Or is there a better way to solve this? You can set the preferred technology in ConnMan main.conf file (typically found in /etc/connman directory) like this PreferredTechnologies = cellular,ethernet More information in ConnMan sources in src/main.conf example file. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v3] wifi: disconnect if wpa_s state changes from completed to scanning
Hi Pasi,
On ke, 2015-05-06 at 14:22 +0300, pasi.sjoh...@jolla.com wrote:
> From: Pasi Sjöholm
>
> It's possible from wpa_s to change the state from completed to scanning
> without going through disconnected state if interface signals that the carrier
> went off and on (IFF_LOWER_UP flag).
>
> This will cause dead lock similar in c810464828d6764bea304de3e9b6b151aa05e313
> if the wifi gets into associating state as the network->connected is still
> true
> but wifi->connected is not.
> ---
> plugins/wifi.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index d0d7917..a22faae 100755
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -2341,6 +2341,9 @@ static void interface_state(GSupplicantInterface
> *interface)
>
> switch (state) {
> case G_SUPPLICANT_STATE_SCANNING:
> + if (wifi->connected)
> + connman_network_set_connected(network, false);
> +
> break;
>
> case G_SUPPLICANT_STATE_AUTHENTICATING:
> @@ -2435,6 +2438,13 @@ static void interface_state(GSupplicantInterface
> *interface)
> else
> wifi->connected = false;
> break;
> + case G_SUPPLICANT_STATE_SCANNING:
> + if (wifi->connected) {
> + wifi->connected = false;
> + start_autoscan(device);
> + } else
> + wifi->connected = false;
> + break;
or you could just say
+ if (wifi->connected)
+ start_autoscan(device);
+
+ wifi->connected = false;
+ break;
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: re-connecting to enterprise network
Hi Tom, On ke, 2015-04-29 at 00:44 +, Thomas Green wrote: > All, > > I successfully connect to an enterprise AP, then at some point change to a > different AP, and finally attempt to switch back to the original enterprise > AP. The connection seems to be remembering the identity and passphrase that > I originally used to connect, as the agent isn't called to prompt for them. > At this point the association phase fails, and the debugging output is clear > that it is moving from association to failure. The message error I get back > from dbus is "GDBus.Error:net.connman.Error.Failed: Input/output error". If, > at this time I try yet again to connect to the enterprise AP no previous > values are remembered, and the agent again prompts me for the identity and > passphrase, and the connection completes. It would seem as if the failed > attempt did not send the proper identity and passphrase. Is it possible to > tell exactly what is being passed on the association phase? If you are on 1.29, then I just wonder if this commit 346609214f05b3b4eb49a2b1b03844d94e9eb59d could cause this. Can you revert that commit and see if it changes things? Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Hidden network with different APs.
Hi Pedro, On ke, 2015-04-15 at 09:45 +0200, Pedro Erencia wrote: > Hi Jason, > > The AP is a dlink-DAP 2590. > > The Wireless band is fixed to 2.4 GHz, the Channel is fixed to 6 and the > Channel width to 20 MHz. > > I've repeated the test. After rebooting the AP the frequency changed from > 2467 to 2422. > > I've changed the frequency in the settings file and, voila, it worked. > > Again, powering off changes the frequency from 2422 to 2462. Changing the > settings makes connman connect correctly. > > @Jukka: This does not happens when the AP is non-hidden. Frequency changed > from 2412 to 2457, still connman reconnects properly. > > What should be the solution ? Creating a new wifi_xxx folder (why is not > doing it now ?) or ignoring the frequency when dealing with hidden networks ? I just sent a patch called "wifi: Do not add frequency to hidden AP scan" that ignores the frequency for hidden AP scan. Can you try if it fixes the issue. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] wifi: Do not add frequency to hidden AP scan
It seems that wpa_supplicant gets confused if we pass frequency to scan params when trying to connect to hidden AP. Fixes CM-676 --- plugins/wifi.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/plugins/wifi.c b/plugins/wifi.c index 1f90a31..42dd407 100644 --- a/plugins/wifi.c +++ b/plugins/wifi.c @@ -992,7 +992,7 @@ static int get_hidden_connections(GSupplicantScanParams *scan_data) GKeyFile *keyfile; gchar **services; char *ssid, *name; - int i, freq, ret; + int i, ret; bool value; int num_ssids = 0, add_param_failed = 0; @@ -1022,13 +1022,10 @@ static int get_hidden_connections(GSupplicantScanParams *scan_data) ssid = g_key_file_get_string(keyfile, services[i], "SSID", NULL); - freq = g_key_file_get_integer(keyfile, services[i], - "Frequency", NULL); - name = g_key_file_get_string(keyfile, services[i], "Name", NULL); - ret = add_scan_param(ssid, NULL, 0, freq, scan_data, 0, name); + ret = add_scan_param(ssid, NULL, 0, 0, scan_data, 0, name); if (ret < 0) add_param_failed++; else if (ret > 0) -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Hidden network with different APs.
On ti, 2015-04-14 at 19:23 -0700, Jason Abele wrote: > On Tue, Apr 14, 2015 at 12:25:58PM +0200, Pedro Erencia wrote: > > As a workaround I'd try to always remove the wifi_xxx_ folders until a > > solution is found. Any other ideas ? > > Could you check if the AP is changing frequencies each time you power-cycle > it? > > My guess is that the AP is set to auto-select a frequency on boot, so > connman does not find the hidden network on the same frequency the second > time (the last successful frequency is stored in the config file). > > Please let us know which frequency your AP is using. > > iw wlan0 scan | grep -e '^BSS' -e 'SSID' -e 'freq:' The used frequency should not matter as ConnMan will do a scan anyway to find the hidden AP. I am just wondering if this issue is related to hidden AP. Pedro, have you tested whether your client can autoconnect if you make your AP non-hidden? Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Hidden network with different APs.
Hi Pedro, On ti, 2015-04-14 at 12:25 +0200, Pedro Erencia wrote: > Any idea about that ? > > I was thinking about filling a bug report but it seems I must be granted > access to Jira (Patrik?) > You need first to create an account to 01.org from this link (or access it directly from main page), https://01.org/user/register And after that just login using your new credentials https://01.org/jira/login.jsp?os_destination=%2Fbrowse%2FCM Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Hidden network with different APs.
Hi Pedro, On ma, 2015-04-13 at 13:49 +0200, Pedro Erencia wrote: > Hi. > > > > We are facing some problems regarding hidden SSIDs. To summarize, if a > connection has been correctly established with a hidden SSID (so a wifi__ > folder is created), if the AP is rebooted connman fails to remember the > network: > > > > To reproduce it I did the following: > > - Start the device with no wifi_ folders and a .config according to the > testing AP. > >* The connection is established automatically correctly. > > - Power off the device and the AP. > > - After the AP is on, start the device. > >* No connection is established (though I see the hidden AP in the service > list). If I try to connect credentials are asked. > > - Remove the wifi__ folder > > - Restart the device. > >* The connection is established automatically correctly. > > - From this point on, as long as the AP is not powered off, the device > >reestablishes the connection properly. > > > > One of our customers complained about having to re-enter the credentials > every time a new AP in the SSID was reached. I think that’s the same case. > > > > This happens with connman 1.28. Did you try this with a patch called "service: Do not clear passphrase or identity on error" that Patrik sent last Thursday to ml? I checked the ConnMan code and it looks like that patch should fix the issue you are seeing. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[RFC 0/3] DNS proxy fixes
Hi, Slava noticed that dnsproxy.c does not set request buffer for UDP requests but leaves it NULL. This is fixed in patch 1 by Slava. I added that patch into this set (and added more details into commit message) as this is very much RFC material. After this patchset the UDP packet resending when the resolver is flushed starts to work after many years of failure. The resolver is flushed every time name servers are updated. This happens even if we disconnect a service which is very much pointless (some more patches will be sent to fix this later). What all this means, is that the UDP packet re-send and failure notifications to calling resolver client has not been working at all for some time. For UDP packets that the dnsproxy sends to external DNS servers, the req->request buffer was NULL. This then meant that the dnsproxy code that tries to send message to client in a case of failure cannot really do anything. The successful request was passed correctly to the client that sent the initial DNS request. So the issue has been the failure case when the external DNS server is not responding. There should be no similar issues in TCP side. Fortunately no one has reported this issue as the client app resolver (libc) still has its own timeout and everything is fine if there is an resolver error in ConnMan side. Anyway, the changes in patch 1 activate now some code paths that have not been in use for some time. So this set needs more testing in order not to introduce more bugs. Because everything seems to work just fine at the moment with the current code, it is quite possible that we could remove even more extra cruft from dnsproxy.c instead of introducing these fixes in this set. So if we do not apply patch 1, we could save some memory by removing dead code. By applying patch 1, more memory is consumed as we need to save the request buffer for each UDP DNS request. Patch 2 removes the numserv check in request_timeout() because it is pointless as we need to send some data to client anyway. Earlier this code path was not taken for UDP packets (because the req->request buffer was NULL). I also refactored the request_timeout() in patch 3 as it had duplicate code and was hard to follow. Cheers, Jukka Jukka Rissanen (2): dnsproxy: Do not check numserv in request timeout dnsproxy: Refactor the request_timeout() function Slava Monich (1): dnsproxy: request_data in request_list need the request data for UDP src/dnsproxy.c | 67 -- 1 file changed, 32 insertions(+), 35 deletions(-) -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[RFC 1/3] dnsproxy: request_data in request_list need the request data for UDP
From: Slava Monich UDP packet did not set the request and request_len properly. This is seen in valgrind report. ==7180== Syscall param socketcall.sendto(msg) points to unaddressable byte(s) ==7180==at 0x4B9CE34: sendto (in /lib/libc-2.15.so) ==7180==by 0x79283: ns_resolv (dnsproxy.c:1644) ==7180==by 0x7977F: resolv (dnsproxy.c:2648) ==7180==by 0x7C80F: __connman_dnsproxy_flush (dnsproxy.c:2770) ==7180==by 0x47C37: update_nameservers (service.c:1158) ==7180==by 0x47F27: __connman_service_nameserver_remove (service.c:1275) ==7180==by 0x5D87B: dhcp_invalidate (dhcp.c:133) ==7180==by 0x5E677: __connman_dhcp_stop (dhcp.c:641) ==7180==by 0x3F9CB: set_disconnected (network.c:746) ==7180==by 0x4079B: connman_network_set_connected (network.c:1465) ==7180==by 0x21563: interface_state (wifi.c:1824) ==7180==by 0x2648B: callback_interface_state (supplicant.c:377) ==7180==by 0x2648B: interface_property (supplicant.c:1854) ==7180==by 0x28DBF: supplicant_dbus_property_foreach (dbus.c:145) ==7180==by 0x22B7F: g_supplicant_filter (supplicant.c:2636) ==7180==by 0x497AF4F: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.7.12) ==7180==by 0x81C57: message_dispatch (mainloop.c:72) ==7180==by 0x48ABA8B: g_idle_dispatch (gmain.c:5251) ==7180==by 0x48AFB1F: g_main_dispatch (gmain.c:3066) ==7180==by 0x48AFB1F: g_main_context_dispatch (gmain.c:3642) ==7180==by 0x48AFE23: g_main_context_iterate.part.19 (gmain.c:3713) ==7180==by 0x48B048B: g_main_loop_run (gmain.c:3906) ==7180==by 0x149D3: main (main.c:761) ==7180== Address 0x0 is not stack'd, malloc'd or (recently) free'd| --- src/dnsproxy.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/dnsproxy.c b/src/dnsproxy.c index 9787b68..0698387 100644 --- a/src/dnsproxy.c +++ b/src/dnsproxy.c @@ -3467,6 +3467,9 @@ static bool udp_listener_event(GIOChannel *channel, GIOCondition condition, return true; } + req->name = g_strdup(query); + req->request = g_malloc(len); + memcpy(req->request, buf, len); req->timeout = g_timeout_add_seconds(5, request_timeout, req); request_list = g_slist_append(request_list, req); -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[RFC 2/3] dnsproxy: Do not check numserv in request timeout
The req->numserv tries to track that we have received all the
answers from different servers. This is pointless when the request
is about to go away as we need to send something to the client
in this case anyway.
---
src/dnsproxy.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/dnsproxy.c b/src/dnsproxy.c
index 0698387..2a0a94a 100644
--- a/src/dnsproxy.c
+++ b/src/dnsproxy.c
@@ -538,7 +538,6 @@ static gboolean request_timeout(gpointer user_data)
DBG("id 0x%04x", req->srcid);
request_list = g_slist_remove(request_list, req);
- req->numserv--;
if (req->resplen > 0 && req->resp) {
int sk, err;
@@ -558,7 +557,7 @@ static gboolean request_timeout(gpointer user_data)
}
if (err < 0)
return FALSE;
- } else if (req->request && req->numserv == 0) {
+ } else if (req->request) {
struct domain_hdr *hdr;
if (req->protocol == IPPROTO_TCP) {
--
2.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[RFC 3/3] dnsproxy: Refactor the request_timeout() function
Combine the common code so that the function is easier to read
and understand.
---
src/dnsproxy.c | 61 +++---
1 file changed, 28 insertions(+), 33 deletions(-)
diff --git a/src/dnsproxy.c b/src/dnsproxy.c
index 2a0a94a..cf3490c 100644
--- a/src/dnsproxy.c
+++ b/src/dnsproxy.c
@@ -531,6 +531,8 @@ static void destroy_request_data(struct request_data *req)
static gboolean request_timeout(gpointer user_data)
{
struct request_data *req = user_data;
+ struct sockaddr *sa;
+ int sk;
if (!req)
return FALSE;
@@ -539,45 +541,37 @@ static gboolean request_timeout(gpointer user_data)
request_list = g_slist_remove(request_list, req);
- if (req->resplen > 0 && req->resp) {
- int sk, err;
+ if (req->protocol == IPPROTO_UDP) {
+ sk = get_req_udp_socket(req);
+ sa = &req->sa;
+ } else if (req->protocol == IPPROTO_TCP) {
+ sk = req->client_sk;
+ sa = NULL;
+ } else
+ goto out;
- if (req->protocol == IPPROTO_UDP) {
- sk = get_req_udp_socket(req);
- if (sk < 0)
- return FALSE;
+ if (req->resplen > 0 && req->resp) {
+ /*
+* Here we have received at least one reply (probably telling
+* "not found" result), so send that back to client instead
+* of more fatal server failed error.
+*/
+ if (sk >= 0)
+ sendto(sk, req->resp, req->resplen, MSG_NOSIGNAL,
+ sa, req->sa_len);
- err = sendto(sk, req->resp, req->resplen, MSG_NOSIGNAL,
- &req->sa, req->sa_len);
- } else {
- sk = req->client_sk;
- err = send(sk, req->resp, req->resplen, MSG_NOSIGNAL);
- if (err < 0)
- close(sk);
- }
- if (err < 0)
- return FALSE;
} else if (req->request) {
+ /*
+* There was not reply from server at all.
+*/
struct domain_hdr *hdr;
- if (req->protocol == IPPROTO_TCP) {
- hdr = (void *) (req->request + 2);
- hdr->id = req->srcid;
- send_response(req->client_sk, req->request,
- req->request_len, NULL, 0, IPPROTO_TCP);
-
- } else if (req->protocol == IPPROTO_UDP) {
- int sk;
-
- hdr = (void *) (req->request);
- hdr->id = req->srcid;
+ hdr = (void *)(req->request + protocol_offset(req->protocol));
+ hdr->id = req->srcid;
- sk = get_req_udp_socket(req);
- if (sk >= 0)
- send_response(sk, req->request,
- req->request_len, &req->sa,
- req->sa_len, IPPROTO_UDP);
- }
+ if (sk >= 0)
+ send_response(sk, req->request, req->request_len,
+ sa, req->sa_len, req->protocol);
}
/*
@@ -590,6 +584,7 @@ static gboolean request_timeout(gpointer user_data)
GINT_TO_POINTER(req->client_sk));
}
+out:
req->timeout = 0;
destroy_request_data(req);
--
2.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] dnsproxy: request_data in request_list need the request data
On ti, 2015-04-07 at 12:58 +0300, Slava Monich wrote: > On 07/04/15 12:14, Patrik Flykt wrote: > > Hi, > > > > On Thu, 2015-04-02 at 21:36 +0300, Slava Monich wrote: > >> The ones received over UDP didn't have it. > >> --- > >> src/dnsproxy.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/src/dnsproxy.c b/src/dnsproxy.c > >> index 9787b68..0698387 100644 > >> --- a/src/dnsproxy.c > >> +++ b/src/dnsproxy.c > >> @@ -3467,6 +3467,9 @@ static bool udp_listener_event(GIOChannel *channel, > >> GIOCondition condition, > >>return true; > >>} > >> > >> + req->name = g_strdup(query); > >> + req->request = g_malloc(len); > >> + memcpy(req->request, buf, len); > >>req->timeout = g_timeout_add_seconds(5, request_timeout, req); > >>request_list = g_slist_append(request_list, req); > >> > > To me it seems only TCP is using req->name, so not all code paths need > > to set it. What issues did you notice before this patch? > > |==7180== Syscall param socketcall.sendto(msg) points to unaddressable byte(s) > ==7180==at 0x4B9CE34: sendto (in /lib/libc-2.15.so) > ==7180==by 0x79283: ns_resolv (dnsproxy.c:1644) > ==7180==by 0x7977F: resolv (dnsproxy.c:2648) > ==7180==by 0x7C80F: __connman_dnsproxy_flush (dnsproxy.c:2770) > ==7180==by 0x47C37: update_nameservers (service.c:1158) > ==7180==by 0x47F27: __connman_service_nameserver_remove (service.c:1275) > ==7180==by 0x5D87B: dhcp_invalidate (dhcp.c:133) > ==7180==by 0x5E677: __connman_dhcp_stop (dhcp.c:641) > ==7180==by 0x3F9CB: set_disconnected (network.c:746) > ==7180==by 0x4079B: connman_network_set_connected (network.c:1465) > ==7180==by 0x21563: interface_state (wifi.c:1824) > ==7180==by 0x2648B: callback_interface_state (supplicant.c:377) > ==7180==by 0x2648B: interface_property (supplicant.c:1854) > ==7180==by 0x28DBF: supplicant_dbus_property_foreach (dbus.c:145) > ==7180==by 0x22B7F: g_supplicant_filter (supplicant.c:2636) > ==7180==by 0x497AF4F: dbus_connection_dispatch (in > /usr/lib/libdbus-1.so.3.7.12) > ==7180==by 0x81C57: message_dispatch (mainloop.c:72) > ==7180==by 0x48ABA8B: g_idle_dispatch (gmain.c:5251) > ==7180==by 0x48AFB1F: g_main_dispatch (gmain.c:3066) > ==7180==by 0x48AFB1F: g_main_context_dispatch (gmain.c:3642) > ==7180==by 0x48AFE23: g_main_context_iterate.part.19 (gmain.c:3713) > ==7180==by 0x48B048B: g_main_loop_run (gmain.c:3906) > ==7180==by 0x149D3: main (main.c:761) > ==7180== Address 0x0 is not stack'd, malloc'd or (recently) free'd| FYI, something like this trace would be really nice to see in the commit message. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] configure: Add option to set path of the pptp binary
User can set the path to client binary using --with-pptp option.
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index 85c01b9..5eb5a34 100644
--- a/configure.ac
+++ b/configure.ac
@@ -146,6 +146,9 @@ fi
AM_CONDITIONAL(L2TP, test "${enable_l2tp}" != "no")
AM_CONDITIONAL(L2TP_BUILTIN, test "${enable_l2tp}" = "builtin")
+AC_ARG_WITH(pptp, AC_HELP_STRING([--with-pptp=PROGRAM],
+[specify location of pptp binary]), [path_pptp=${withval}])
+
AC_ARG_ENABLE(pptp,
AC_HELP_STRING([--enable-pptp], [enable pptp support]),
[enable_pptp=${enableval}], [enable_pptp="no"])
--
2.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] configure: Add option to set path of the l2tp binary
User can set the path to client binary using --with-l2tp option.
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index cec10bf..85c01b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -121,6 +121,9 @@ fi
AM_CONDITIONAL(VPNC, test "${enable_vpnc}" != "no")
AM_CONDITIONAL(VPNC_BUILTIN, test "${enable_vpnc}" = "builtin")
+AC_ARG_WITH(l2tp, AC_HELP_STRING([--with-l2tp=PROGRAM],
+[specify location of l2tp binary]), [path_l2tp=${withval}])
+
AC_ARG_ENABLE(l2tp,
AC_HELP_STRING([--enable-l2tp], [enable l2tp support]),
[enable_l2tp=${enableval}], [enable_l2tp="no"])
--
2.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] inet: fixed the check of inet_pton return value
Hi Slava,
On to, 2015-04-02 at 12:20 +0300, Slava Monich wrote:
> On 02/04/15 09:14, Patrik Flykt wrote:
> > @@ -634,17 +634,15 @@ int connman_inet_add_ipv6_network_route(int index,
> > const char *host,
> >
> > rt.rtmsg_dst_len = prefix_len;
> >
> > - if (inet_pton(AF_INET6, host, &rt.rtmsg_dst) < 0) {
> > + if (inet_pton(AF_INET6, host, &rt.rtmsg_dst) < 1) {
> > err = -errno;
> > goto out;
> > }
> >
> > rt.rtmsg_flags = RTF_UP | RTF_HOST;
> >
> > - if (gateway) {
> > + if (gateway && inet_pton(AF_INET6, gateway, &rt.rtmsg_gateway) > 0)
> > rt.rtmsg_flags |= RTF_GATEWAY;
> > - inet_pton(AF_INET6, gateway, &rt.rtmsg_gateway);
> > - }
> > At this point if inet_pton fails, why are we continuing with the
> > rt.rtmsg? Apparently there was a gateway with an unusable IPv6 address
> > so shouldn't we return error instead?
>
>
> In cases where it does happen in reality, even if we return an error,
> the caller (add_nameserver_route) would call
> connman_inet_add_ipv6_network_route again with NULL gateway. This code
> is doing it in one shot but it does make an assumption about what the
> caller actually means by providing an invalid gateway address.
>
> In any case it's better than using bogus gateway address.
As Patrik mentioned, why not just do
if (gateway) {
if (inet_pton(AF_INET6, gateway, &rt.rtmsg_gateway) < 1)
return -EINVAL;
rt.rtmsg_flags |= RTF_GATEWAY;
}
and let caller decide what to do next if gateway address was bogus.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] plugin: vlan: add support for VLAN
Hi Marcus,
On ti, 2015-03-31 at 20:08 +0200, Marcus Folkesson wrote:
> From: Marcus Folkesson
>
> Support for multiple VLANs binded to the same interface.
> VLAN services appear as:
> vlan__
> For example:
> vlan_5c260a4bf6a3_vlan3
>
> Signed-off-by: Marcus Folkesson
> diff --git a/src/rtnl.c b/src/rtnl.c
> index b8b02c4..15827ab 100644
> --- a/src/rtnl.c
> +++ b/src/rtnl.c
> @@ -170,6 +170,9 @@ static void read_uevent(struct interface_data *interface)
> } else if (strcmp(line + 8, "gadget") == 0) {
> interface->service_type = CONNMAN_SERVICE_TYPE_GADGET;
> interface->device_type = CONNMAN_DEVICE_TYPE_GADGET;
> + } else if (strcmp(line + 8, "vlan") == 0) {
> + interface->service_type = CONNMAN_SERVICE_TYPE_VLAN;
> + interface->device_type = CONNMAN_DEVICE_TYPE_VLAN;
>
> } else {
Checked this with ancient 3.2 kernel and for vlan interface there is no
DEVTYPE defined. For newer 3.19 kernel, the DEVTYPE is set to vlan as
expected.
I just wonder would it be possible to treat vlan device as a normal
ethernet device without separation between vlan and ethernet types. This
would solve this issue with different kernel versions.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
Hi Andreas, On to, 2015-03-19 at 12:18 +0100, Andreas Oberritter wrote: > Hi Jukka, > > On 19.03.2015 09:02, Jukka Rissanen wrote: > > Hi Andreas, > > > > On ke, 2015-03-18 at 16:27 +0100, Andreas Oberritter wrote: > >> Booting an nfsroot with connman requires passing -I eth0 to ignore > >> the interface. This isn't very nice, for at least the following > >> reasons: > >> > >> * A User interface based on connman is led to believe that there's no > >> network interface and thus connman seems to be offline when it's not. > >> * The DHCP lease obtained by the kernel won't get renewed. > >> * DNS servers won't get obtained from DHCP, thus requiring a workaround > >> to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. > >> > >> Therefore change behaviour to restrict interfaces passed with -I to > >> read-only ioctls. > >> > > > > I have seen this NFS thing being asked before and one workaround has > > been to use the -I option to ignore the NFS link. This is kind of wrong > > as then the link is not managed and used by ConnMan any more. > > > > I just wonder if we could tweak device.c:cleanup_devices() function to > > skip the NFS link instead of this patch that changes lot of things in > > the code. The cleanup_devices() is cleaning the links when ConnMan > > starts so that connmand has a known initial state. Perhaps we could skip > > the cleaning of NFS link if ConnMan notices that there is such a link. > > This would be less invasive than having these read checks all over the > > place. > > I'll try this and report back. > > Do you think I should add a new command-line option to pass the > interface to ConnMan? Identifying the interface used for NFS requires > parsing /proc/cmdline and, in case of static addresses, knowledge about > the interfaces' IP address. Until now I preferred to let the shell do it. Sure, we can try adding new command line option for that. Although best thing would be to detect NFS link usage at run time inside ConnMan, but I agree it is easier to done in the shell. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
Hi Andreas, On ke, 2015-03-18 at 16:27 +0100, Andreas Oberritter wrote: > Booting an nfsroot with connman requires passing -I eth0 to ignore > the interface. This isn't very nice, for at least the following > reasons: > > * A User interface based on connman is led to believe that there's no > network interface and thus connman seems to be offline when it's not. > * The DHCP lease obtained by the kernel won't get renewed. > * DNS servers won't get obtained from DHCP, thus requiring a workaround > to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. > > Therefore change behaviour to restrict interfaces passed with -I to > read-only ioctls. > I have seen this NFS thing being asked before and one workaround has been to use the -I option to ignore the NFS link. This is kind of wrong as then the link is not managed and used by ConnMan any more. I just wonder if we could tweak device.c:cleanup_devices() function to skip the NFS link instead of this patch that changes lot of things in the code. The cleanup_devices() is cleaning the links when ConnMan starts so that connmand has a known initial state. Perhaps we could skip the cleaning of NFS link if ConnMan notices that there is such a link. This would be less invasive than having these read checks all over the place. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman connection policy
Hi Ram,
On ke, 2015-03-18 at 13:12 +, Kallumari Nagaraja Rao, RammohanX
wrote:
> Hello Jukka,
>
> Is the Agent request input happens via a dictionary ?
Yes, the passphrase is sent as a dictionary element. See
doc/agent-api.txt document for details (there are some examples at the
end of the document).
> I was able to register a agent handler & getting RequestInput from the
> ConnMan.
> However I am unable to send out the passphrase out.
>
> static DBusHandlerResult request_passkey_message(DBusConnection *conn,
> DBusMessage *msg)
> {
> DBusMessage *reply;
> DBusError derr, error;
> const char *device;
> char passkey[17] = "micromax";
> const char *psk = "micromax";
>
> reply = dbus_message_new_method_return(msg);
> if (!reply)
> return DBUS_HANDLER_RESULT_NEED_MEMORY;
>
> dbus_error_init(&derr);
> if (!dbus_message_get_args(msg, &derr, DBUS_TYPE_OBJECT_PATH, &device,
> DBUS_TYPE_INVALID)) {
> fprintf(stderr, "%s", derr.message);
> dbus_error_free(&derr);
> return error_message(conn, msg, "net.connman.Error.Rejected",
> "Wrong signature");
> }
>
> if (device)
> printf("Device: %s\n", device);
>
> //memset(passkey, 0, sizeof(passkey));
> printf("Passkey sent over: %s\n", psk);
>
> dbus_message_append_args(reply, DBUS_TYPE_STRING, &psk,
> DBUS_TYPE_INVALID);
>
> dbus_connection_send(conn, reply, NULL);
>
> printf("reply success\n");
>
> dbus_message_unref(reply);
>
> return DBUS_HANDLER_RESULT_HANDLED;
> }
>
> I guess the passkey is currently sent out as a string & the ConnMan may not
> be able to accept it.
> Not sure how to convert the input into a dictionary & append my passphrase
> into it.
I am sure you can search the web for examples how to send a dictionary
in dbus from C-program.
>
> I am able to print the service properly.
>
> Please help me on this. Thanks.
>
> Regards,
>
>
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: connman connection policy
On ti, 2015-03-17 at 10:25 +, Kallumari Nagaraja Rao, RammohanX
wrote:
> This is what I tried doing it, I am very new to these stuffs :(
>
> DBusMessage * agent_update_passphrase(DBusConnection *connection, char *
> serv_str, char * pass)
> {
> DBusMessage *message, *reply;
> DBusError error;
> DBusMessageIter iter;
> DBusMessageIter args;
> static char *path = NULL;
> char *property = "Passphrase";
> int type = DBUS_TYPE_STRING;
> char *param = AGENT_PATH;
>
> path = g_strdup_printf("/net/connman/service/%s", serv_str);
> message = dbus_message_new_method_call( CONNMAN_SERVICE,
>
> path,
>
> CONNMAN_AGENT_INTERFACE,
>
> "RequestInput" );
This is wrong. ConnMan will call RequestInput method so you will need to
create a listener in your application for that. You are not suppose to
call RequestInput in ConnMan as there will not be such method there.
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Issues with connection to hidden network
Hi Wawrzek, On to, 2015-02-19 at 12:44 +, Wawrzek Niewodniczanski wrote: > Hi, > > I've got a problem(s) with connection to our office wifi networks > using connman. This email is about connection to hidden network (I had > problem with WPA2, but that's the story for another email). > > > Connman: 1.21-1build1 (from Ubuntu 14.10) with both connmanctl and > econnman (from Bodhi). > Hardware: Dell XPS 13 with 02:00.0 Network controller: Intel > Corporation Wireless 7260 (rev 6b) You ConnMan version is ancient. If possible try to upgrade the latest and greatest version 1.28. Also make sure that wpa_supplicant does not have CONFIG_AUTOSCAN_EXPONENTIAL enabled, see this commit for more details http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=82571d6542c15af2dc0304babb98d8542fc043f4 > > I've got a problem with connman for a long time (since I start to use > it with Ubuntu 14.04 half year ago). I'm only person having them and > there is a mix of Windows and Linux users (but not connman users). > > Connman quite often 'loses' password to hidden network in question > (the password is saved in /var/lib/connman/wifi_xxx_yyy_managed_psk) > and I have to retype it after coming to the office (but only > sometimes). Today it reached next level - it stopped to work at all. I > type password as requested in econnman and there is no connection. > > From commandline I got: > > connmanctl> connect wifi_28b2bda10ba8_626c696e6b782d68696464656e_managed_psk > Error > /net/connman/service/wifi_28b2bda10ba8_626c696e6b782d68696464656e_managed_psk: > Method "Connect" with signature "" on interface "net.connman.Service" > doesn't exist > > > What interesting I have two wifi matching the hidden network: > > * -hiddenwifi_28b2bda10ba8_hidden_managed_psk > *A -hidden > wifi_28b2bda10ba8_626c696e6b782d68696464656e_managed_psk The latter service looks bogus. > > > What does that error message means? The AP was lost i.e., wpa_supplicant timed out the AP as it was not found in scan. > What should I look in connmand logs? > Why I cannot connect to wifi services? > Why are there two 'services'? That is a bug, please upgrade. > > Thanks, > Wawrzek > Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [RFC v2] network: Merge identical ipconfig code paths
Hi Patrik,
On ke, 2015-02-11 at 13:54 +0200, Patrik Flykt wrote:
> Configure IPv4 and IPv6 configurations only once in
> __connman_network_enable_ipconfig() and use this function when setting
> the network connected. Remove obsolete function and rework the rest
> to centralise configuration state and error reporting.
>
> The variable network->connecting is true as long as the IPv4 or IPv6
> address configuration phase is ongoing.
> ---
>
>
> Hi,
>
> This is a fairly large patch that removes duplicate code in set_connected()
> in favor of using the one in __connman_network_set_ipconfig(). There is
> no change in functionality in this patch.
>
> v2 fixes a glitch with variable naming wrt rebasing
>
>
> Please test,
>
>Patrik
>
>
> src/connman.h | 5 +-
> src/network.c | 218
> +-
> src/service.c | 21 +++---
> 3 files changed, 80 insertions(+), 164 deletions(-)
>
> diff --git a/src/connman.h b/src/connman.h
> index 8d4a692..d4765cc 100644
> --- a/src/connman.h
> +++ b/src/connman.h
> @@ -587,9 +587,8 @@ int __connman_network_connect(struct connman_network
> *network);
> int __connman_network_disconnect(struct connman_network *network);
> int __connman_network_clear_ipconfig(struct connman_network *network,
> struct connman_ipconfig *ipconfig);
> -int __connman_network_set_ipconfig(struct connman_network *network,
> - struct connman_ipconfig *ipconfig_ipv4,
> - struct connman_ipconfig *ipconfig_ipv6);
> +int __connman_network_enable_ipconfig(struct connman_network *network,
> + struct connman_ipconfig *ipconfig);
>
> const char *__connman_network_get_type(struct connman_network *network);
> const char *__connman_network_get_group(struct connman_network *network);
> diff --git a/src/network.c b/src/network.c
> index 0cef220..253966e 100644
> --- a/src/network.c
> +++ b/src/network.c
> @@ -153,10 +153,6 @@ static void dhcp_success(struct connman_network *network)
> if (!service)
> goto err;
>
> - connman_network_set_associating(network, false);
> -
> - network->connecting = false;
> -
> ipconfig_ipv4 = __connman_service_get_ip4config(service);
>
> DBG("lease acquired for ipconfig %p", ipconfig_ipv4);
> @@ -188,9 +184,6 @@ static void dhcp_failure(struct connman_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);
> @@ -206,55 +199,24 @@ static void dhcp_callback(struct connman_ipconfig
> *ipconfig,
> struct connman_network *network,
> bool success, gpointer data)
> {
> + network->connecting = false;
> +
> if (success)
> dhcp_success(network);
> else
> dhcp_failure(network);
> }
>
> -static int set_connected_fixed(struct connman_network *network)
> -{
> - struct connman_service *service;
> - struct connman_ipconfig *ipconfig_ipv4;
> - int err;
> -
> - DBG("");
> -
> - service = connman_service_lookup_from_network(network);
> -
> - ipconfig_ipv4 = __connman_service_get_ip4config(service);
> -
> - set_configuration(network, CONNMAN_IPCONFIG_TYPE_IPV4);
> -
> - network->connecting = false;
> -
> - connman_network_set_associating(network, false);
> -
> - err = __connman_ipconfig_address_add(ipconfig_ipv4);
> - if (err < 0)
> - goto err;
> -
> - err = __connman_ipconfig_gateway_add(ipconfig_ipv4);
> - if (err < 0)
> - goto err;
> -
> - return 0;
> -
> -err:
> - connman_network_set_error(network,
> - CONNMAN_NETWORK_ERROR_CONFIGURE_FAIL);
> -
> - return err;
> -}
> -
> -static void set_connected_manual(struct connman_network *network)
> +static int set_connected_manual(struct connman_network *network)
> {
> + int err = 0;
> struct connman_service *service;
> struct connman_ipconfig *ipconfig;
> - int err;
>
> DBG("network %p", network);
>
> + network->connecting = false;
> +
> service = connman_service_lookup_from_network(network);
>
> ipconfig = __connman_service_get_ip4config(service);
> @@ -262,8 +224,6 @@ static void set_connected_manual(struct connman_network
> *network)
> if (!__connman_ipconfig_get_local(ipconfig))
> __connman_service_read_ip4config(service);
>
> - set_configuration(network, CONNMAN_IPCONFIG_TYPE_IPV4);
> -
> err = __connman_ipconfig_address_add(ipconfig);
> if (err < 0)
> goto err;
> @@ -272,16 +232,8 @@ static void set_connected_manual(struct connman_network
> *network)
> if (err < 0)
>
Re: [PATCH] Add setting: UpdateResolvConf
On ke, 2015-02-04 at 15:53 +0100, Martin Tournoij wrote: > On Wed, Feb 4, 2015, at 15:41, Jukka Rissanen wrote: > > Just wondering where do you get the nameserver IP addresses in this > > case? Are you manually updating resolv.conf? > > Not sure if I understand this question? I mean where does unbound gets its names resolved, are you using 8.8.8.8 or similar global service? > > Let me explain my setup in more detail: > > - Run unbound on 127.0.0.54 > > - Run adsuck on 127.0.0.53, this filters ad domains (spoofs reply with > 127.0.0.2), and forwards other queries to 127.0.0.42 (unbound). > > - Start connman with --nodnsproxy > > - For the root user, run a crontab with: > */5 * * * * echo 'nameserver 127.0.0.53' > /etc/resolv.conf > > unbound works as recursive resolver, no other DNS server required. > > This works, except for the first 0 to 5 minutes I connected to a new > network. It's also more than a bit ugly... > > Is this a very esoteric setup? I don't know ... It makes sense to me to This is very exotic setup :) You might be able to configure connman to use your 127.0.0.53 server by configuring it to each service you are using (have not tested this thou). Example: connmanctl config your_service_id --nameservers 127.0.0.53 and then running connman with dnsproxy enabled. > not use every random DNS server out there... DNSSEC should ensure I get > responses that haven't been tampered with... I don't know what random > DNS servers do at starbucks do... > > Thanks, > Martin Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Add setting: UpdateResolvConf
Hi Martin, On ke, 2015-02-04 at 15:34 +0100, Martin Tournoij wrote: > On Wed, Feb 4, 2015, at 15:28, Patrik Flykt wrote: > > > > Hi, > > > > On Wed, 2015-02-04 at 15:23 +0100, Martin Tournoij wrote: > > > > How do you pick up the DNS servers when changing networks if ConnMan > > > > never writes the ones obtained via DHCP anywhere? How do you update > > > the > > > > DNS servers at the moment when using your own resolver? > > > > > > I don't. I run unbound (& adsuck) on my laptop, so it works > > > everywhere. > > > > So if you do a lookup for 'slashdot.org', how is unbound configured to > > properly resolve that name from any network you visit? Google? > > It just works as a recursive resolver, I don't need to rely on any > "external" DNS resolvers (which is how unbound works by default). Just wondering where do you get the nameserver IP addresses in this case? Are you manually updating resolv.conf? Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman vs networkmanager today
Hi Vasiliy, On ke, 2015-01-28 at 13:51 +0400, Vasiliy Tolstov wrote: > 2015-01-12 12:07 GMT+03:00 Tomasz Bursztyka > : > > ConnMan does not support ipsec yet. > > > Do you have any plans to add this kind of support? As i understand we > simply need to spawn xl2tp client... ? > I sent in 2012 one proposal for IPSec, more details in this thread https://lists.syncevolution.org/pipermail/connman/2012-January/007916.html At that time it was agreed that IPSec functionality would need to be integrated more tightly into ConnMan instead of being launched as a separate daemon (racoon). If you are able to contribute, patches are welcome. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/2] gdhcp: Server id must not be converted to host byte order
As the server_nip is already in network byte order, we must not
convert the received server id option to host byte order.
This used to work as we sent the server id in wrong byte order
and then swapped it back here. But because of previous fix to
sent the server id in network byte order, this receiving end
needs some changes also.
---
gdhcp/server.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gdhcp/server.c b/gdhcp/server.c
index 97c16c2..8574c24 100644
--- a/gdhcp/server.c
+++ b/gdhcp/server.c
@@ -668,7 +668,8 @@ static gboolean listener_event(GIOChannel *channel,
GIOCondition condition,
server_id_option = dhcp_get_option(&packet, DHCP_SERVER_ID);
if (server_id_option) {
- uint32_t server_nid = get_be32(server_id_option);
+ uint32_t server_nid =
+ get_unaligned((const uint32_t *) server_id_option);
if (server_nid != dhcp_server->server_nip)
return TRUE;
--
1.8.3.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/2] gdhcp: Set DHCP server id option in network byte order
The DHCP server id option was sent using host byte order instead of
network byte order. If the client uses the value when sending data
to the server, then the DHCP packet will contain IP address in
wrong byte order.
This issue was noticed with P2P connections where we do not set
the gateway address in DHCP messages so some P2P clients sent data
to wrong server as the our server address was incorrect.
---
gdhcp/server.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gdhcp/server.c b/gdhcp/server.c
index 8561dd3..97c16c2 100644
--- a/gdhcp/server.c
+++ b/gdhcp/server.c
@@ -56,7 +56,7 @@ struct _GDHCPServer {
char *interface;
uint32_t start_ip;
uint32_t end_ip;
- uint32_t server_nip;
+ uint32_t server_nip;/* our address in network byte order */
uint32_t lease_seconds;
int listener_sockfd;
guint listener_watch;
@@ -454,7 +454,7 @@ static void init_packet(GDHCPServer *dhcp_server, struct
dhcp_packet *packet,
packet->gateway_nip = client_packet->gateway_nip;
packet->ciaddr = client_packet->ciaddr;
dhcp_add_option_uint32(packet, DHCP_SERVER_ID,
- dhcp_server->server_nip);
+ ntohl(dhcp_server->server_nip));
}
static void add_option(gpointer key, gpointer value, gpointer user_data)
--
1.8.3.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] dhcpv6: Calculate re-transmission timer correctly
The conversion from uint64_t to float caused the RT value
to become 0. This caused the transmission timeout to expire
immediately and the machine load to go to 100%.
This is fixed by using directly uints instead of floats.
---
src/dhcpv6.c | 49 +
1 file changed, 29 insertions(+), 20 deletions(-)
diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index c311045..9249e55 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -105,28 +105,37 @@ static void clear_timer(struct connman_dhcpv6 *dhcp)
}
}
-static inline float get_random(void)
+static inline guint get_random(void)
{
uint64_t val;
__connman_util_get_random(&val);
- return (val % 200 - 100) / 1000.0;
+
+ /* Make sure the value is always positive so strip MSB */
+ return ((uint32_t)val) >> 1;
+}
+
+static guint compute_random(guint val)
+{
+ return val - val / 10 +
+ (get_random() % (2 * 1000)) * val / 10 / 1000;
}
/* Calculate a random delay, RFC 3315 chapter 14 */
/* RT and MRT are milliseconds */
static guint calc_delay(guint RT, guint MRT)
{
- float delay = get_random();
- float rt = RT * (2 + delay);
+ if (MRT && (RT > MRT / 2))
+ RT = compute_random(MRT);
+ else
+ RT += compute_random(RT);
- if (rt > MRT)
- rt = MRT * (1 + delay);
-
- if (rt < 0)
- rt = MRT;
+ return RT;
+}
- return (guint)rt;
+static guint initial_rt(guint timeout)
+{
+ return compute_random(timeout);
}
static void free_prefix(gpointer data)
@@ -1223,7 +1232,7 @@ static gboolean start_rebind(gpointer user_data)
if (check_restart(dhcp) < 0)
return FALSE;
- dhcp->RT = REB_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(REB_TIMEOUT);
DBG("rebind initial RT timeout %d msec", dhcp->RT);
@@ -1390,7 +1399,7 @@ static gboolean start_renew(gpointer user_data)
{
struct connman_dhcpv6 *dhcp = user_data;
- dhcp->RT = REN_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(REN_TIMEOUT);
DBG("renew initial RT timeout %d msec", dhcp->RT);
@@ -1588,7 +1597,7 @@ static gboolean start_info_req(gpointer user_data)
struct connman_dhcpv6 *dhcp = user_data;
/* Set the retransmission timeout, RFC 3315 chapter 14 */
- dhcp->RT = INF_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(INF_TIMEOUT);
DBG("info initial RT timeout %d msec", dhcp->RT);
@@ -1655,7 +1664,7 @@ static void advertise_cb(GDHCPClient *dhcp_client,
gpointer user_data)
return;
}
- dhcp->RT = REQ_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(REQ_TIMEOUT);
DBG("request initial RT timeout %d msec", dhcp->RT);
dhcp->timeout = g_timeout_add(dhcp->RT, timeout_request, dhcp);
@@ -1766,7 +1775,7 @@ static gboolean start_solicitation(gpointer user_data)
struct connman_dhcpv6 *dhcp = user_data;
/* Set the retransmission timeout, RFC 3315 chapter 14 */
- dhcp->RT = SOL_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(SOL_TIMEOUT);
DBG("solicit initial RT timeout %d msec", dhcp->RT);
@@ -2178,7 +2187,7 @@ static gboolean start_pd_rebind(gpointer user_data)
if (check_pd_restart(dhcp) < 0)
return FALSE;
- dhcp->RT = REB_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(REB_TIMEOUT);
DBG("rebind initial RT timeout %d msec", dhcp->RT);
@@ -2230,7 +2239,7 @@ static gboolean start_pd_rebind_with_confirm(gpointer
user_data)
{
struct connman_dhcpv6 *dhcp = user_data;
- dhcp->RT = CNF_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(CNF_TIMEOUT);
DBG("rebind with confirm initial RT timeout %d msec", dhcp->RT);
@@ -2267,7 +2276,7 @@ static gboolean start_pd_renew(gpointer user_data)
{
struct connman_dhcpv6 *dhcp = user_data;
- dhcp->RT = REN_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(REN_TIMEOUT);
DBG("renew initial RT timeout %d msec", dhcp->RT);
@@ -2483,7 +2492,7 @@ static void advertise_pd_cb(GDHCPClient *dhcp_client,
gpointer user_data)
return;
}
- dhcp->RT = REQ_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(REQ_TIMEOUT);
DBG("request initial RT timeout %d msec", dhcp->RT);
dhcp->timeout = g_timeout_add(dhcp->RT, timeout_pd_request, dhcp);
@@ -2538,7 +2547,7 @@ static gboolean start_pd_solicitation(gpointer user_data)
struct connman_dhcpv6 *dhcp = user_data;
/* Set the retransmission timeout, RFC 3315 chapter 14 */
- dhcp->RT = SOL_TIMEOUT * (1 + get_random());
+ dhcp->RT = initial_rt(SOL_TIMEOUT);
DBG("solicit initial RT timeout %d msec", dhcp->RT);
--
1.8.3.1
___
connman mailing list
connman@
Re: [PATCH 3/6] ofono: Old nameservers need to be cleared
Hi Pasi, On to, 2014-12-18 at 14:42 +, Pasi Sjöholm wrote: > >> If ipv4_method is dhcp there will be no address, and neither there > >> will an address with ipv6 when dual-mode (slaac & dhcpv6) is used. > >> So we just can jump into conlusions.. > >So this all is about DHCP then...? > > and SLAAC.. which does not provide any method to configure the DNS-servers > and we can/should not use the old values from any previous > configuration/active context. There is a RFC for it, see https://tools.ietf.org/html/rfc6106 for details. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] service: Send changed type signal
On to, 2014-12-11 at 12:24 +0200, Tomasz Bursztyka wrote:
> Hi,
>
> NACK.
>
> > From: Chengyi Zhao
> >
> > ---
> > src/service.c | 31 ++-
> > 1 file changed, 30 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/service.c b/src/service.c
> > index 9bba227..6c8b2a2 100644
> > --- a/src/service.c
> > +++ b/src/service.c
> > @@ -183,7 +183,7 @@ const char *__connman_service_type2string(enum
> > connman_service_type type)
> > {
> > switch (type) {
> > case CONNMAN_SERVICE_TYPE_UNKNOWN:
> > - break;
> > + return "unknown";
>
> No, if a service type is unknown this functions returns NULL, and that's it.
> You will never ever get a service through service list which owns a type
> "unknown".
> Or if it is, there will be serious bug around.
>
> > case CONNMAN_SERVICE_TYPE_SYSTEM:
> > return "system";
> > case CONNMAN_SERVICE_TYPE_ETHERNET:
> > @@ -1423,9 +1423,30 @@ bool __connman_service_index_is_default(int index)
> > return __connman_service_get_index(service) == index;
> > }
> >
> > +static void type_changed(struct connman_service *service)
> > +{
> > + const char *str;
> > +
> > + if (!service)
> > + return;
> > +
> > + if (!allow_property_changed(service))
> > + return;
> > +
> > + str = __connman_service_type2string(service->type);
> > + if (!str)
> > + return;
> > +
> > + connman_dbus_property_changed_basic(service->path,
> > + CONNMAN_SERVICE_INTERFACE, "Type",
> > + DBUS_TYPE_STRING, &str);
> > +}
>
> The type of a service never changes, this signal is useless.
>
> > +
> > static void default_changed(void)
> > {
> > struct connman_service *service = __connman_service_get_default();
> > + enum connman_service_type old_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
> > + enum connman_service_type new_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
> >
> > if (service == current_default)
> > return;
> > @@ -1436,6 +1457,11 @@ static void default_changed(void)
> >
> > __connman_service_timeserver_changed(current_default, NULL);
> >
> > + if (current_default)
> > + old_type = current_default->type;
> > + if (service)
> > + new_type = service->type;
> > +
> > current_default = service;
> >
> > if (service) {
> > @@ -1448,6 +1474,9 @@ static void default_changed(void)
> > }
> >
> > __connman_notifier_default_changed(service);
> > +
> > + if (old_type != new_type)
> > + type_changed(service);
> > }
>
> This does not make any sense.
> The type of the previous default service or the new one has not changed.
> Sure, the previous service could have a different type than the new one,
> but themselves
> they haven't changed their type.
To Chengyi:
if you want to know what is the current type of default service, you can
get that information from service properties. You just need to listen
the service PropertyChanged signals and get the type from there.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Conflict with udev for interface name
Hi Frederic, On ma, 2014-12-01 at 15:51 +0100, frederic.wo...@continental-corporation.com wrote: > Hello all, > > I'd like to predefine the name on one of my network interface using udev > rule but get an error as usb0 is already in use probably by connmand. Why do you think it is connmand? Connman just gets rtnl events when interface name is changed (usually by systemd-udevd) and tries to avoid using the interface name because the name can change (interface index is used instead in the code). > Any advice how to make it work ? > > Here the extract on udevadm test /sys/class/net/usb0 > ... > NAME 'usb_s5' /usr/lib/udev/rules.d/80-net-name-slot.rules:16 > RUN '/usr/lib/systemd/systemd-sysctl > --prefix=/proc/sys/net/ipv4/conf/$name > --prefix=/proc/sys/net/ipv4/neigh/$name > --prefix=/proc/sys/net/ipv6/conf/$name > --prefix=/proc/sys/net/ipv6/neigh/$name' > /usr/lib/udev/rules.d/99-systemd.rules:52 > changing net interface name from 'usb0' to 'usb_s5' > error changing net interface name usb0 to usb_s5: Device or resource busy > ... > > fred Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman not bringing up interfaces
Hi Tim, On to, 2014-11-06 at 11:41 -0500, Tim Tisdall wrote: > I have connman 1.26 working in linaro (ubuntu derivative for arm devices) > off of an sdcard. However, when I move the OS to the NAND drive the > network adapters don't automatically come up as they did before when > running off the sdcard. I am able to manually call "ifconfig wlan0 up" and > then things work fine, but I thought connman was able to do this > automatically. I also tried manually restarting connman after booting to > see if it would bring up the interfaces itself, but it didn't. Sounds like wifi technology is not powered/enabled. You can enable it with "connmanctl enable wifi" command. > > What could cause such a thing? > > -Tim Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Preconfiguring wired Ethernet interfaces
Hi Ryan, On ma, 2014-10-27 at 09:44 -0500, Ryan Kuester wrote: > Hi all, > > There's a thread[1] from early 2013 which concluded that the way to > statically configure wired Ethernet interfaces that are not connected is > by writing .config files to /var/lib/connman/. In my case, this seems to > require: > >1. Discovering the MAC addresses of the two interfaces by external > means, that is, not via a connman interface. > >2. Writing a .config file in /var/lib/connman/ using the discovered > MAC addresses and my desired settings. > >3. Restarting connmand for the settings in the .config files to take > effect. This is not needed as connman will monitor /var/lib/connman and use the found .config files automatically. > >4. Reading the .config files in order to show the desired > configuration in a user interface. You should use the ConnMan dbus API to get the configuration in a UI. The provisioned services are almost identical to normal services, only difference is that the provisioned ones have immutable flag set which means that you can edit only minimal subset of service properties. > >5. Repeating steps 2 and 3 any time a user makes changes. > > Is this still the state of the art? > > -- Ryan > > -- > 1. https://lists.connman.net/pipermail/connman/2013-January/012729.html Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gweb: Enable TLSv1.2 and TLSv1.1
Hi Pasi, On su, 2014-10-19 at 00:33 +0300, pasi.sjoh...@jolla.com wrote: > From: Pasi Sjöholm > > As the web servers are migrating away from SSLv3 more secure > protocols need to be enabled. I just wonder should we just disable sslv3 support all together? > > Thanks for Hannu Mallat noticing this. > --- > gweb/giognutls.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/gweb/giognutls.c b/gweb/giognutls.c > index 09dc9e7..687bf8f 100644 > --- a/gweb/giognutls.c > +++ b/gweb/giognutls.c > @@ -456,7 +456,8 @@ GIOChannel *g_io_channel_gnutls_new(int fd) > "NORMAL:%COMPAT", NULL); > #else > gnutls_priority_set_direct(gnutls_channel->session, > - "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT", NULL); > + "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2:+VERS-TLS1.1:" \ > + "+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT", NULL); > #endif > > gnutls_certificate_allocate_credentials(&gnutls_channel->cred); Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman refusing to find wifi
Hi Matti, On 13 October 2014 21:23, Matti Laakso wrote: > Hi Jukka, > >>> >>> I'm running Yocto Linux 1.4 with connman 1.12 and wpa_supplicant 2.0. I Yep, Yocto 1.4 (dylan) has new dbus interface activated. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/defconfig-gnutls?h=dylan >>> >>> # ./test-new-supplicant >>> ERROR:dbus.proxies:Introspect error on :1.2:/fi/w1/wpa_supplicant1: >>> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: >>> wpa_supplicant was compiled without introspection support. This would really indicate an issue with new dbus interface but as you said it should be acticated in wpa_s. >>> >>> I'm able to connect wifi with wpa_supplicant alone. >> >> It looks like your wpa_supplicant is not compiled with new dbus API. >> So check from wpa_supplicant config file that you have >> >> # Add support for new DBus control interface >> # (fi.w1.hostap.wpa_supplicant1) >> CONFIG_CTRL_IFACE_DBUS_NEW=y >> >> >> Check also ConnMan README file, it contains information about the >> settings you need to activate in wpa_s. >> > > I do have CONFIG_CTRL_IFACE_DBUS_NEW enabled. I also tried > 'supplicant-test' (which seems to only use the new interface) with mixed > results: > > # supplicant-test > supplicant: Startup > ^Csupplicant: Terminating > supplicant: Exit > > i.e., it fails to start wpa_supplicant with the new DBus interface. However, > if I first > start wpa_supplicant by hand (wpa_supplicant -u -B), it works: > > # supplicant-test > supplicant: Startup > supplicant: service_property() Debug level 2 > supplicant: service_property() Debug timestamp 0 > supplicant: service_property() Debug show keys 0 > supplicant: debug_strvalmap() EAP method: MD5 > supplicant: debug_strvalmap() EAP method: TLS > supplicant: debug_strvalmap() EAP method: MSCHAPV2 > supplicant: debug_strvalmap() EAP method: PEAP > supplicant: debug_strvalmap() EAP method: TTLS > supplicant: debug_strvalmap() EAP method: GTC > supplicant: debug_strvalmap() EAP method: OTP > supplicant: debug_strvalmap() EAP method: LEAP > supplicant: service_property() key Capabilities type a > supplicant: system_ready() * > ... > > and so on, detecting wlan0 and a bunch of networks. ConnMan still won't find > wifi, however. > So it seems that the new interface is there, and works, but it can't be used > to start > wpa_supplicant (even though the dbus service file is there and has correct > content). > Could this be a permissions issue? I also think that out of the settings from > ConnMan > README I'm missing CONFIG_WPS and CONFIG_AP, are they absolutely needed? > I'll try recompiling with them later. Yes, it could be a permission problem. Would you able to upgrade connman, with Yocto that is quite trivial. I have also used Yocto but newer version than what you are using and have had no issues with wifi. I had to specify some options for wpa_s that were not found in standard Yocto. See http://git.yoctoproject.org/cgit/cgit.cgi/meta-eca/ and http://git.yoctoproject.org/cgit/cgit.cgi/meta-eca/tree/meta-eca/recipes-connectivity/wpa-supplicant for details. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman refusing to find wifi
Hi Matti,
On la, 2014-10-11 at 22:15 +0300, Matti Laakso wrote:
> Hi,
>
> I'm running Yocto Linux 1.4 with connman 1.12 and wpa_supplicant 2.0. I
> know it's not the latest and greatest, but I hope you are still able to
> help. I'm basically unable to get connman to recognize wpa_supplicant.
> Starting 'connmand -d -n' I get
>
> connmand[1478]: src/technology.c:technology_get() No matching drivers
> found for wifi.
>
> Furthermore, 'connmanctl technologies' lists only wired, and 'connmanctl
> enable wifi' doesn't produce any output.
>
> Connman is built with --enable-wifi (there is only tist.so under
> /usr/lib/connman/plugins, but as far as I've understood, wifi is
> built-in). At least 'strings /usr/sbin/connmand' produces a lot of
> wifi-related output.
>
> Wpa_supplicant is built with D-Bus support:
>
> # ls /usr/share/dbus-1/system-services/
> fi.epitest.hostap.WPASupplicant.service
> fi.w1.wpa_supplicant1.service
> org.bluez.service
>
> # ls /etc/dbus-1/system.d/
> bluetooth.confconnman.conf dbus-wpa_supplicant.conf
>
> # dbus-send --system --dest=org.freedesktop.DBus --type=method_call
> --print-reply /org/freedesktop/DBus
> org.freedesktop.DBus.ListActivatableNames
> method return sender=org.freedesktop.DBus -> dest=:1.24 reply_serial=2
>array [
> string "org.freedesktop.DBus"
> string "fi.epitest.hostap.WPASupplicant"
> string "fi.w1.wpa_supplicant1"
> string "org.bluez"
>]
>
> test-supplicant seems to work:
>
> # ./test-supplicant
> state = INACTIVE
> scanning = 0
> [ /fi/epitest/hostap/WPASupplicant/Interfaces/0 ]
> group = CCMP TKIP WEP104 WEP40
> proto = RSN WPA
> auth_alg = OPEN SHARED LEAP
> pairwise = CCMP TKIP
> eap = MD5 TLS MSCHAPV2 PEAP TTLS GTC OTP LEAP
> key_mgmt = NONE IEEE8021X WPA-EAP WPA-PSK
> scanning = 0
> state = INACTIVE
> dbus.Array([dbus.ObjectPath('/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/f81a67a2de43'),
> dbus.ObjectPath('/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/000cc37e945c'),
> dbus.ObjectPath('/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/bcee7b555134'),
> dbus.ObjectPath('/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/001a9f94f5aa'),
> dbus.ObjectPath('/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/ee43f62dd5a4'),
> dbus.ObjectPath('/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/002207ecfc5d')],
> signature=dbus.Signature('o'))
> [ /fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/f81a67a2de43 ]
> ssid = dbus.Array([dbus.Byte(65), dbus.Byte(110), dbus.Byte(100),
> dbus.Byte(114), dbus.Byte(111), dbus.Byte(109), dbus.Byte(101),
> dbus.Byte(100), dbus.Byte(97)], signature=dbus.Signature('y'),
> variant_level=1) bssid =
> dbus.Array([dbus.Byte(248), dbus.Byte(26), dbus.Byte(103),
> dbus.Byte(162), dbus.Byte(222), dbus.Byte(67)],
> signature=dbus.Signature('y'),
> variant_level=1)
> level = -67
> capabilities = 17
> frequency = 2412
> maxrate = 5400
> quality = 43
> rsnie = dbus.Array([dbus.Byte(48), dbus.Byte(20), dbus.Byte(1),
> dbus.Byte(0), dbus.Byte(0), dbus.Byte(15), dbus.Byte(172), dbus.Byte(4),
> dbus.Byte(1), dbus.Byte(0), dbus.Byte(0), dbus.Byte(15), dbus.Byte(172),
> dbus.Byte(4), dbus.Byte(1), dbus.Byte(0), dbus.Byte(0), dbus.Byte(15),
> dbus.Byte(172), dbus.Byte(2), dbus.Byte(12), dbus.Byte(0)],
> signature=dbus.Signature('y'), variant_level=1)
>
> but test-new-supplicant gives an error:
>
> # ./test-new-supplicant
> ERROR:dbus.proxies:Introspect error on :1.2:/fi/w1/wpa_supplicant1:
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
> wpa_supplicant was compiled without introspection support.
>
> I'm able to connect wifi with wpa_supplicant alone.
It looks like your wpa_supplicant is not compiled with new dbus API.
So check from wpa_supplicant config file that you have
# Add support for new DBus control interface
# (fi.w1.hostap.wpa_supplicant1)
CONFIG_CTRL_IFACE_DBUS_NEW=y
Check also ConnMan README file, it contains information about the
settings you need to activate in wpa_s.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] dnxproxy: Enable DNS on non-default services if there is no default
Hi Justin,
On to, 2014-10-09 at 12:54 -0700, Justin Maggard wrote:
> If your service has not switched to an Online state but has always been
Is your service always in ready state, or do you mean that you are
transitioning from ready->online and something goes wrong?
> Ready, an IP change on that service will cause DNS to stop working.
What do you mean by IP change here?
> This is because that service will have never been marked as the default;
First service in the service list (whether it is in ready or online
states) will be the default. So there should always be a default service
if at least one service is in ready state.
> so when dnxproxy goes to re-add the DNS server(s) for the service, it will
> not enable it.
Can you explain a bit more how do you trigger this issue, I have not
seen one even if I all my services are in ready state.
>
> Fix it by making sure we actually have a default service first, before
> deciding that we should not enable DNS on a non-default service.
>
> Signed-off-by: Justin Maggard
> ---
> src/dnsproxy.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/dnsproxy.c b/src/dnsproxy.c
> index bdd7fd5..837aff6 100644
> --- a/src/dnsproxy.c
> +++ b/src/dnsproxy.c
> @@ -2604,6 +2604,7 @@ static struct server_data *create_server(int index,
>
> if (protocol == IPPROTO_UDP) {
> if (__connman_service_index_is_default(data->index) ||
> + !__connman_service_get_default() ||
> __connman_service_index_is_split_routing(
> data->index)) {
> data->enabled = true;
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Connman tethering landing page (or single dns record pointing back to itself)
Hi Olliver, On ti, 2014-10-07 at 12:50 +0200, Olliver Schinagl wrote: > Hey Jukka, > > On 07-10-14 12:06, Jukka Rissanen wrote: > > Hi Olliver, > > > > On ti, 2014-10-07 at 10:44 +0200, Olliver Schinagl wrote: > >> Hey list, > >> > >> for our embedded project, we are trying to use connman to take care of > >> all the basic networking. > >> > >> Currently, connman is used in tethering mode to setup an access point > >> for initial configuration of the device. We use an app for that and > >> right now, it seems that connman's dhcp server uses a random IP for > >> itself (ip range is of no importance). As you can guess, on some mobile > >> OSes getting things like gateway or DHCP server information is next to > >> impossible, we can only get our own IP. > >> > >> What we wanted to do, is use a dns record, connect.ultimaker.com, which > >> points at a real site to which the app can connect. If the connection > >> succeeds, something went wrong as we are not talking to the connman host > >> directly. So our first plan was to have connman's dnsproxy answer to > >> connect.ultimaker.com with its own randomly selected IP. I have found > >> out that connman however does not support injecting DNS records into its > >> cache. So first question is, does connman have a hostname that points to > >> itself to obtain the tether IP from? > > I have used avahi and mdns to do just that. So the host where connman is > > running is also running avahi and then that host can be connected as > > your-hostname.local from tethering client. > Ah yes of course! We are going to use avahi eventually, so that can > probably used indeed! Just for my information, avahi daemon knows its IP > as soon as it is set by connmand, an ahavi client announces to the > network that it's here and listening (which is cleaner then just looking > for the daemon?) mdns listens on all interfaces on port 53 like a > regular DNS server allowing name resolution? Only connman is listening on 53 as seen in this listing (I am tethering wifi in this example) root@eca:~# lsof -i :53 -n COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME connmand 350 root 10u IPv4 14030 0t0 UDP 127.0.0.1:domain connmand 350 root 11u IPv6 14034 0t0 UDP [::1]:domain connmand 350 root 12u IPv4 14038 0t0 TCP 127.0.0.1:domain (LISTEN) connmand 350 root 13u IPv6 14042 0t0 TCP [::1]:domain (LISTEN) connmand 350 root 18u IPv4 16451 0t0 UDP 192.168.0.1:domain connmand 350 root 19u IPv4 16462 0t0 TCP 192.168.0.1:domain (LISTEN) avahi is listening on these ports in my test setup avahi-dae 324 avahi 12u IPv4 13879 0t0 UDP *:mdns avahi-dae 324 avahi 13u IPv4 13880 0t0 UDP *:45638 r Avahi does its magic nicely and can co-exists with connman without any problems. > >> Secondly, assuming the first thing fails, we where looking for if > >> connman has a method to redirect all traffic to a landing page of some > >> sort, wasn't wispr something used for this? This would work equally well > >> as the name resolving part I expect and allows for webbrowers to get a > >> usefull page when connected to the landing page. > > No such feature exists in connman. We are only supporting wispr when > > connman acts as a client. > Alright, fair enough. > > > >> Thirdly, we where then thinking of using a tun device, with a static IP > >> and putting that in the tether group, allowing the device always to be > >> reached on a fixed address and then disable connman's proxy cache and > >> use dnsmasq to have the dns address to the tun device IP. The question > >> here would then be, connman only uses resolv.conf to find the real dns > >> server before replacing it with itself? E.g. no port can be specified > >> right? (e.g. dnsmasq + connman living happily together, ugly but could > >> work). > > If you disable connman dnsproxy, then you can run dnsmasq in the same > > host. > and mdns right? Sure, no issues there. > > > >> Lastly I suppose, if nothing in the above can be used to solve this > >> issue (except for a patch which in time may come) any other thoughts of > >> tackle the problem for a connected tethering client to connect to the > >> tether host. > > avahi+mdns would be the easiest choice if your client OS supports that. > linux is our OS of choice! I like your choices :) Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman tethering landing page (or single dns record pointing back to itself)
Hi Olliver, On ti, 2014-10-07 at 10:44 +0200, Olliver Schinagl wrote: > Hey list, > > for our embedded project, we are trying to use connman to take care of > all the basic networking. > > Currently, connman is used in tethering mode to setup an access point > for initial configuration of the device. We use an app for that and > right now, it seems that connman's dhcp server uses a random IP for > itself (ip range is of no importance). As you can guess, on some mobile > OSes getting things like gateway or DHCP server information is next to > impossible, we can only get our own IP. > > What we wanted to do, is use a dns record, connect.ultimaker.com, which > points at a real site to which the app can connect. If the connection > succeeds, something went wrong as we are not talking to the connman host > directly. So our first plan was to have connman's dnsproxy answer to > connect.ultimaker.com with its own randomly selected IP. I have found > out that connman however does not support injecting DNS records into its > cache. So first question is, does connman have a hostname that points to > itself to obtain the tether IP from? I have used avahi and mdns to do just that. So the host where connman is running is also running avahi and then that host can be connected as your-hostname.local from tethering client. > > Secondly, assuming the first thing fails, we where looking for if > connman has a method to redirect all traffic to a landing page of some > sort, wasn't wispr something used for this? This would work equally well > as the name resolving part I expect and allows for webbrowers to get a > usefull page when connected to the landing page. No such feature exists in connman. We are only supporting wispr when connman acts as a client. > > Thirdly, we where then thinking of using a tun device, with a static IP > and putting that in the tether group, allowing the device always to be > reached on a fixed address and then disable connman's proxy cache and > use dnsmasq to have the dns address to the tun device IP. The question > here would then be, connman only uses resolv.conf to find the real dns > server before replacing it with itself? E.g. no port can be specified > right? (e.g. dnsmasq + connman living happily together, ugly but could > work). If you disable connman dnsproxy, then you can run dnsmasq in the same host. > > Lastly I suppose, if nothing in the above can be used to solve this > issue (except for a patch which in time may come) any other thoughts of > tackle the problem for a connected tethering client to connect to the > tether host. avahi+mdns would be the easiest choice if your client OS supports that. > > Thank you, > > Olliver > Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH v2] gdhcp: Workaround for buggy AP that handle broadcast flag incorrectly
Some routers/AP handle the DHCP broadcast flag incorrectly.
This means that some AP discard the DHCP packet if broadcast
flag is present and some discard it if broadcast flag is missing.
The workaround is to first send DISCOVER packet in INIT state without
broadcast flag. If there is a timeout we send the second packet with
broadcast flag set. In a case of second timeout the next DISCOVER will
not set broadcast flag etc.
In REBOOTING state the REQUEST packet will not set the broadcast flag.
If we do not get a reply, we switch to INIT state anyway which will
set the broadcast flag.
---
Hi,
this is v2 of the DHCP broadcast flag handling. This version will by
default start with unicast flag and only if there is no reply we
try with broadcast flag.
Cheers,
Jukka
gdhcp/client.c | 52 +---
gdhcp/common.c | 8 +---
gdhcp/common.h | 3 ++-
gdhcp/server.c | 4 ++--
4 files changed, 54 insertions(+), 13 deletions(-)
diff --git a/gdhcp/client.c b/gdhcp/client.c
index 16fe080..66c3a90 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -155,6 +155,7 @@ struct _GDHCPClient {
uint32_t expire;
bool retransmit;
struct timeval start_time;
+ bool request_bcast;
};
static inline void debug(GDHCPClient *client, const char *format, ...)
@@ -455,15 +456,26 @@ static int send_discover(GDHCPClient *dhcp_client,
uint32_t requested)
add_send_options(dhcp_client, &packet);
+ /*
+* If we do not get a reply to DISCOVER packet, then we try with
+* broadcast flag set. So first packet is sent without broadcast flag,
+* first retry is with broadcast flag, second retry is without it etc.
+* Reason is various buggy routers/AP that either eat the other or vice
+* versa. In the receiving side we then find out what kind of packet
+* the server can send.
+*/
return dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
- INADDR_BROADCAST, SERVER_PORT,
- MAC_BCAST_ADDR, dhcp_client->ifindex);
+ INADDR_BROADCAST, SERVER_PORT,
+ MAC_BCAST_ADDR, dhcp_client->ifindex,
+ dhcp_client->retry_times % 2);
}
static int send_request(GDHCPClient *dhcp_client)
{
struct dhcp_packet packet;
- debug(dhcp_client, "sending DHCP request");
+
+ debug(dhcp_client, "sending DHCP request (state %d)",
+ dhcp_client->state);
init_packet(dhcp_client, &packet, DHCPREQUEST);
@@ -493,8 +505,9 @@ static int send_request(GDHCPClient *dhcp_client)
dhcp_client->server_ip, SERVER_PORT);
return dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
- INADDR_BROADCAST, SERVER_PORT,
- MAC_BCAST_ADDR, dhcp_client->ifindex);
+ INADDR_BROADCAST, SERVER_PORT,
+ MAC_BCAST_ADDR, dhcp_client->ifindex,
+ dhcp_client->request_bcast);
}
static int send_release(GDHCPClient *dhcp_client,
@@ -1186,6 +1199,7 @@ GDHCPClient *g_dhcp_client_new(GDHCPType type,
dhcp_client->duid_len = 0;
dhcp_client->last_request = time(NULL);
dhcp_client->expire = 0;
+ dhcp_client->request_bcast = false;
*error = G_DHCP_CLIENT_ERROR_NONE;
@@ -1293,7 +1307,8 @@ static bool sanity_check(struct ip_udp_dhcp_packet
*packet, int bytes)
return true;
}
-static int dhcp_recv_l2_packet(struct dhcp_packet *dhcp_pkt, int fd)
+static int dhcp_recv_l2_packet(struct dhcp_packet *dhcp_pkt, int fd,
+ struct sockaddr_in *dst_addr)
{
int bytes;
struct ip_udp_dhcp_packet packet;
@@ -1338,6 +1353,8 @@ static int dhcp_recv_l2_packet(struct dhcp_packet
*dhcp_pkt, int fd)
if (dhcp_pkt->cookie != htonl(DHCP_MAGIC))
return -1;
+ dst_addr->sin_addr.s_addr = packet.ip.daddr;
+
return bytes - (sizeof(packet.ip) + sizeof(packet.udp));
}
@@ -2231,6 +2248,7 @@ static gboolean listener_event(GIOChannel *channel,
GIOCondition condition,
gpointer user_data)
{
GDHCPClient *dhcp_client = user_data;
+ struct sockaddr_in dst_addr = { 0 };
struct dhcp_packet packet;
struct dhcpv6_packet *packet6 = NULL;
uint8_t *message_type = NULL, *client_id = NULL, *option,
@@ -2257,7 +2275,8 @@ static gboolean listener_event(GIOChannel *channel,
GIOCondition condition,
if (dhcp_client->listen_mode == L2) {
re = dhcp_recv_l2_packet(&packet,
- dhcp_client->listener_sockfd);
+ dhcp_client->listener_sockfd,
+
Re: Connman behavior with marginally stabe wifi
On to, 2014-09-18 at 08:57 +, Thiemo van Engelen wrote: > Hello all, > > Or is this typically solved in the controlling application on embedded > devices and if this is the case, does anyone have some pointers and what and > what not to do to get it going again without user interaction? > The controlling application can use the ConnMan session API to create the connections. See API description at http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/session-api.txt Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] Fix fallback nameservers harder
From: Andreas Hartmetz
- Make sure to insert them with the enabled flag set. No need to
touch the flag afterwards. When they are not supposed to be used,
they are removed entirely anyway.
- Insert the fallbacks also when taking some service offline.
As I understand it, the fallbacks are for all cases where there is
no other nameserver, including with everything ConnMan knows about
disconnected. It may or may not have originally been meant that way,
in any case it's what we need in our current project.
---
Hi,
sending this to ml on behalf of Andreas so that the patch is not lost.
Cheers,
Jukka
src/dnsproxy.c | 5 +
src/service.c | 1 +
2 files changed, 6 insertions(+)
diff --git a/src/dnsproxy.c b/src/dnsproxy.c
index 741cd45..ba1bd1e 100644
--- a/src/dnsproxy.c
+++ b/src/dnsproxy.c
@@ -2603,6 +2603,7 @@ static struct server_data *create_server(int index,
if (protocol == IPPROTO_UDP) {
if (__connman_service_index_is_default(data->index) ||
+ data->index < 0 ||
__connman_service_index_is_split_routing(
data->index)) {
data->enabled = true;
@@ -2788,6 +2789,10 @@ static void dnsproxy_offline_mode(bool enabled)
for (list = server_list; list; list = list->next) {
struct server_data *data = list->data;
+ /* fallback nameservers (index < 0) are always enabled if
present */
+ if (data->index < 0)
+ continue;
+
if (!enabled) {
DBG("Enabling DNS server %s", data->server);
data->enabled = true;
diff --git a/src/service.c b/src/service.c
index e284e92..1e2218b 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1048,6 +1048,7 @@ static void update_nameservers(struct connman_service
*service)
case CONNMAN_SERVICE_STATE_FAILURE:
case CONNMAN_SERVICE_STATE_DISCONNECT:
connman_resolver_remove_all(index);
+ connman_resolver_flush();
return;
case CONNMAN_SERVICE_STATE_READY:
case CONNMAN_SERVICE_STATE_ONLINE:
--
1.8.3.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 3/4] gdhcp: Fix memory leak when clearing option hash
The option list was not freed after individual options were removed. This is the valgrind report of the issue ==16972== 24 bytes in 1 blocks are definitely lost in loss record 81 of 262 ==16972==at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16972==by 0x4E7FE6E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E95FAD: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E76A63: g_list_append (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x41297A: listener_event (client.c:1867) ==16972==by 0x4E7A2A5: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E7A627: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E7AA39: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x40FDF6: main (main.c:689) ==16972== ==16972== 192 (144 direct, 48 indirect) bytes in 6 blocks are definitely lost in loss record 227 of 262 ==16972==at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16972==by 0x4E7FE6E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E95FAD: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E76A63: g_list_append (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4126F5: listener_event (client.c:1877) ==16972==by 0x4E7A2A5: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E7A627: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x4E7AA39: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3800.2) ==16972==by 0x40FDF6: main (main.c:689) --- gdhcp/client.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gdhcp/client.c b/gdhcp/client.c index db21e01..16fe080 100644 --- a/gdhcp/client.c +++ b/gdhcp/client.c @@ -1130,6 +1130,7 @@ static void remove_option_value(gpointer data) GList *option_value = data; g_list_foreach(option_value, remove_value, NULL); + g_list_free(option_value); } GDHCPClient *g_dhcp_client_new(GDHCPType type, -- 1.8.3.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 0/4] Misc DHCPv4 patches
Hi, there has been some reports that sometimes ConnMan is not able to get IP address from the server. This was eventually traced to broadcast flag that is transmitted in DHCP packets. Some buggy AP discard the DHCP packet if broadcast flag is present and some discard it if it is missing. This is a nasty problem that patch 4 tries to overcome. As a workaround we send two packets in initial handshake where the other has broadcast flag and the other does not. If the server is discarding the other packet, we notice that and then can find out what kind of packets the server is able to accept. While doing the above workaround, I noticed some other issue in gdhcp code. This are fixed in patches 1-3. Cheers, Jukka Jukka Rissanen (4): gdhcp: Transaction id was not set when receiving L2 packet gdhcp: Transaction id is in network byte order gdhcp: Fix memory leak when clearing option hash gdhcp: Workaround for buggy AP that handle broadcast flag incorrectly gdhcp/client.c | 76 +++--- gdhcp/common.c | 8 --- gdhcp/common.h | 3 ++- gdhcp/server.c | 4 ++-- 4 files changed, 77 insertions(+), 14 deletions(-) -- 1.8.3.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 4/4] gdhcp: Workaround for buggy AP that handle broadcast flag incorrectly
Some routers/AP handle the DHCP broadcast flag incorrectly.
This means that some AP discard the DHCP packet if broadcast
flag is present and some discard it if broadcast flag is missing.
The workaround is to send two DISCOVER packets in INIT state and
two REQUEST packets in REBOOTING state. The first packet does not
set the broadcast flag and the latter one sets it. When response
is received, we check what kind of destination address (unicast or
broadcast) the server used and start to send packets to it having
either broadcast flag set or not.
---
gdhcp/client.c | 72 --
gdhcp/common.c | 8 ---
gdhcp/common.h | 3 ++-
gdhcp/server.c | 4 ++--
4 files changed, 74 insertions(+), 13 deletions(-)
diff --git a/gdhcp/client.c b/gdhcp/client.c
index 16fe080..238a301 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -155,6 +155,7 @@ struct _GDHCPClient {
uint32_t expire;
bool retransmit;
struct timeval start_time;
+ bool request_bcast;
};
static inline void debug(GDHCPClient *client, const char *format, ...)
@@ -436,6 +437,7 @@ static uint16_t dhcp_attempt_secs(GDHCPClient *dhcp_client)
static int send_discover(GDHCPClient *dhcp_client, uint32_t requested)
{
struct dhcp_packet packet;
+ int ret;
debug(dhcp_client, "sending DHCP discover request");
@@ -455,15 +457,30 @@ static int send_discover(GDHCPClient *dhcp_client,
uint32_t requested)
add_send_options(dhcp_client, &packet);
+ /*
+* We send discover packet twice, first without broadcast flag and
+* then with broadcast flag. Reason is various buggy routers/ap that
+* either eat the other or vice versa. In the receiving side we then
+* find out what kind of packet the server can send.
+*/
+ ret = dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
+ INADDR_BROADCAST, SERVER_PORT,
+ MAC_BCAST_ADDR, dhcp_client->ifindex, false);
+ if (ret < 0)
+ return ret;
+
return dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
- INADDR_BROADCAST, SERVER_PORT,
- MAC_BCAST_ADDR, dhcp_client->ifindex);
+ INADDR_BROADCAST, SERVER_PORT,
+ MAC_BCAST_ADDR, dhcp_client->ifindex, true);
}
static int send_request(GDHCPClient *dhcp_client)
{
struct dhcp_packet packet;
- debug(dhcp_client, "sending DHCP request");
+ int ret;
+
+ debug(dhcp_client, "sending DHCP request (state %d)",
+ dhcp_client->state);
init_packet(dhcp_client, &packet, DHCPREQUEST);
@@ -492,9 +509,23 @@ static int send_request(GDHCPClient *dhcp_client)
dhcp_client->requested_ip, CLIENT_PORT,
dhcp_client->server_ip, SERVER_PORT);
- return dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
+ if (dhcp_client->state != REBOOTING)
+ return dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
INADDR_BROADCAST, SERVER_PORT,
- MAC_BCAST_ADDR, dhcp_client->ifindex);
+ MAC_BCAST_ADDR, dhcp_client->ifindex,
+ dhcp_client->request_bcast);
+
+ ret = dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
+ INADDR_BROADCAST, SERVER_PORT,
+ MAC_BCAST_ADDR, dhcp_client->ifindex,
+ false);
+ if (ret < 0)
+ return ret;
+
+ return dhcp_send_raw_packet(&packet, INADDR_ANY, CLIENT_PORT,
+ INADDR_BROADCAST, SERVER_PORT,
+ MAC_BCAST_ADDR, dhcp_client->ifindex,
+ true);
}
static int send_release(GDHCPClient *dhcp_client,
@@ -1186,6 +1217,7 @@ GDHCPClient *g_dhcp_client_new(GDHCPType type,
dhcp_client->duid_len = 0;
dhcp_client->last_request = time(NULL);
dhcp_client->expire = 0;
+ dhcp_client->request_bcast = false;
*error = G_DHCP_CLIENT_ERROR_NONE;
@@ -1293,7 +1325,8 @@ static bool sanity_check(struct ip_udp_dhcp_packet
*packet, int bytes)
return true;
}
-static int dhcp_recv_l2_packet(struct dhcp_packet *dhcp_pkt, int fd)
+static int dhcp_recv_l2_packet(struct dhcp_packet *dhcp_pkt, int fd,
+ struct sockaddr_in *dst_addr)
{
int bytes;
struct ip_udp_dhcp_packet packet;
@@ -1338,6 +1371,8 @@ static int dhcp_recv_l2_packet(struct dhcp_packet
*dhcp_pkt, int fd)
if (dhcp_pkt->cookie != htonl(DHCP_MAGIC))
return -1;
+ dst_addr->sin_addr.s_addr = packet.ip.daddr;
+
return byt
[PATCH 2/4] gdhcp: Transaction id is in network byte order
Print xid in host byte order so that it is easier to match the
value to data in network packet.
---
gdhcp/client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdhcp/client.c b/gdhcp/client.c
index a031501..db21e01 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -2329,7 +2329,7 @@ static gboolean listener_event(GIOChannel *channel,
GIOCondition condition,
return TRUE;
debug(dhcp_client, "received DHCP packet xid 0x%04x "
- "(current state %d)", xid, dhcp_client->state);
+ "(current state %d)", ntohl(xid), dhcp_client->state);
switch (dhcp_client->state) {
case INIT_SELECTING:
--
1.8.3.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/4] gdhcp: Transaction id was not set when receiving L2 packet
The transaction id was always printed as 0x in debug print.
---
gdhcp/client.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gdhcp/client.c b/gdhcp/client.c
index 88c0419..a031501 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -2257,6 +2257,7 @@ static gboolean listener_event(GIOChannel *channel,
GIOCondition condition,
if (dhcp_client->listen_mode == L2) {
re = dhcp_recv_l2_packet(&packet,
dhcp_client->listener_sockfd);
+ xid = packet.xid;
} else if (dhcp_client->listen_mode == L3) {
if (dhcp_client->type == G_DHCP_IPV6) {
re = dhcpv6_recv_l3_packet(&packet6, buf, sizeof(buf),
--
1.8.3.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/2] ipconfig: Do not disable kernel IPv6 support when disabling ipconfig
When ipconfig is disabled, it is not really necessary to disable
IPv6 support. Doing so will lead to issues when switching from
one service to another in the same network interface. User would
see that the IPv6 is disabled in kernel although user has IPv6
enabled in the service.
Thanks to Arjuna S for reporting this.
---
src/ipconfig.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/ipconfig.c b/src/ipconfig.c
index fa4c0d6..ed7dcf8 100644
--- a/src/ipconfig.c
+++ b/src/ipconfig.c
@@ -1701,10 +1701,6 @@ int __connman_ipconfig_disable(struct connman_ipconfig
*ipconfig)
if (ipdevice->config_ipv6 == ipconfig) {
ipconfig_list = g_list_remove(ipconfig_list, ipconfig);
- if (ipdevice->config_ipv6->method ==
- CONNMAN_IPCONFIG_METHOD_AUTO)
- disable_ipv6(ipdevice->config_ipv6);
-
connman_ipaddress_clear(ipdevice->config_ipv6->system);
__connman_ipconfig_unref(ipdevice->config_ipv6);
ipdevice->config_ipv6 = NULL;
--
1.8.3.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/2] network: Set IPv6 ipconfig if it is missing
Following scenario is possible:
- we have a wifi service A connected and IPv6 is enabled for it
- we connect to other IPv6 enabled service B
- the first service is disconnected
- kernel sends rtnl messages related to events that are done
when we connect/disconnect the services
- if A service's link down event is received after we have
received B's link up, then we will remove the ipv6 config
from service B
- this has the effect that IPv6 addresses are not known by
service B any more
So when we receive a reply to router solicitation message,
we check if the IPv6 config is still there in service B.
If it is not, then we can create it so that service gets
the IPv6 config back.
The missing IPv6 config can only happen if we are switching
from one service to another. If we disconnect first service A
and then connect service B, no issues were seen.
---
src/network.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/network.c b/src/network.c
index d3ad83b..baf7ba4 100644
--- a/src/network.c
+++ b/src/network.c
@@ -464,6 +464,7 @@ static void check_dhcpv6(struct nd_router_advert *reply,
unsigned int length, void *user_data)
{
struct connman_network *network = user_data;
+ struct connman_service *service;
GSList *prefixes;
DBG("reply %p", reply);
@@ -499,6 +500,23 @@ static void check_dhcpv6(struct nd_router_advert *reply,
prefixes = __connman_inet_ipv6_get_prefixes(reply, length);
/*
+* If IPv6 config is missing from service, then create it.
+* The ipconfig might be missing if we got a rtnl message
+* that disabled IPv6 config and thus removed it. This
+* can happen if we are switching from one service to
+* another in the same interface. The only way to get IPv6
+* config back is to re-create it here.
+*/
+ service = connman_service_lookup_from_network(network);
+ if (service) {
+ connman_service_create_ip6config(service, network->index);
+
+ __connman_service_ipconfig_indicate_state(service,
+ CONNMAN_SERVICE_STATE_CONFIGURATION,
+ CONNMAN_IPCONFIG_TYPE_IPV6);
+ }
+
+ /*
* We do stateful/stateless DHCPv6 if router advertisement says so.
*/
if (reply->nd_ra_flags_reserved & ND_RA_FLAG_MANAGED)
--
1.8.3.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 0/2] IPv6 ipconfig fixes
Hi, IPv6 can be disabled in the kernel side if we switch from one service to another that use the same network interface (typically these are wifi services). Patch 2 fixes the issue which was reported yesterday by Arjuna S. So when we switch from one service to another, we disable IPv6 for the interface. This is in practice not needed and will lead to weird issues later. After fixing patch 2, Patrik and I noticed that IPv6 config is still missing from the service. This happens because we receive rtnl messages from kernel in certain order i.e., first "up link" to connected service and then "down link" to disconnecting service. Because the services are using same interface, the latter rtnl down message will effectively remove IPv6 config from the connecting service. The fix to this is to re-create the IP config back if this happens. This is fixed in patch 1. Cheers, Jukka Jukka Rissanen (2): network: Set IPv6 ipconfig if missing ipconfig: Do not disable kernel IPv6 support when disabling ipconfig src/ipconfig.c | 4 src/network.c | 18 ++ 2 files changed, 18 insertions(+), 4 deletions(-) -- 1.8.3.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] dhcpv6: Remove CONFIRM message sending when connecting a link
The CONFIRM message is not sent any more as it does not make much
sense because we do not save address expiration time so we cannot
really know how long the saved address is valid anyway.
The reply to CONFIRM message does not send expiration times back
to us so we cannot get them from server either. Because of this
we need to start using SOLICITATION anyway when a link is
connected.
Thanks to Pasi Sjöholm for reporting this.
---
src/dhcpv6.c | 164 +--
1 file changed, 12 insertions(+), 152 deletions(-)
diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index dee2d81..a1a6e92 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -1769,145 +1769,11 @@ static gboolean start_solicitation(gpointer user_data)
return FALSE;
}
-static void confirm_cb(GDHCPClient *dhcp_client, gpointer user_data)
-{
- struct connman_dhcpv6 *dhcp = user_data;
- int status = g_dhcpv6_client_get_status(dhcp_client);
-
- DBG("dhcpv6 confirm msg %p status %d", dhcp, status);
-
- clear_timer(dhcp);
-
- g_dhcpv6_client_clear_retransmit(dhcp_client);
-
- /*
-* If confirm fails, start from scratch.
-*/
- if (status != 0) {
- g_dhcp_client_unref(dhcp->dhcp_client);
- start_solicitation(dhcp);
- } else {
- do_dad(dhcp_client, dhcp);
- }
-}
-
-static int dhcpv6_confirm(struct connman_dhcpv6 *dhcp)
-{
- GDHCPClient *dhcp_client;
- GDHCPClientError error;
- struct connman_service *service;
- struct connman_ipconfig *ipconfig_ipv6;
- int index, ret;
-
- DBG("dhcp %p", dhcp);
-
- index = connman_network_get_index(dhcp->network);
-
- dhcp_client = g_dhcp_client_new(G_DHCP_IPV6, index, &error);
- if (error != G_DHCP_CLIENT_ERROR_NONE) {
- clear_timer(dhcp);
- return -EINVAL;
- }
-
- if (getenv("CONNMAN_DHCPV6_DEBUG"))
- g_dhcp_client_set_debug(dhcp_client, dhcpv6_debug, "DHCPv6");
-
- service = connman_service_lookup_from_network(dhcp->network);
- if (!service) {
- clear_timer(dhcp);
- g_dhcp_client_unref(dhcp_client);
- return -EINVAL;
- }
-
- ret = set_duid(service, dhcp->network, dhcp_client, index);
- if (ret < 0) {
- clear_timer(dhcp);
- g_dhcp_client_unref(dhcp_client);
- return ret;
- }
-
- g_dhcp_client_set_request(dhcp_client, G_DHCPV6_CLIENTID);
- g_dhcp_client_set_request(dhcp_client, G_DHCPV6_RAPID_COMMIT);
-
- ipconfig_ipv6 = __connman_service_get_ip6config(service);
- dhcp->use_ta = __connman_ipconfig_ipv6_privacy_enabled(ipconfig_ipv6);
-
- g_dhcpv6_client_set_ia(dhcp_client, index,
- dhcp->use_ta ? G_DHCPV6_IA_TA : G_DHCPV6_IA_NA,
- NULL, NULL, TRUE,
- __connman_ipconfig_get_dhcp_address(ipconfig_ipv6));
-
- clear_callbacks(dhcp_client);
-
- g_dhcp_client_register_event(dhcp_client,
- G_DHCP_CLIENT_EVENT_CONFIRM,
- confirm_cb, dhcp);
-
- dhcp->dhcp_client = dhcp_client;
-
- return g_dhcp_client_start(dhcp_client, NULL);
-}
-
-static gboolean timeout_confirm(gpointer user_data)
-{
- struct connman_dhcpv6 *dhcp = user_data;
-
- dhcp->RT = calc_delay(dhcp->RT, CNF_MAX_RT);
-
- DBG("confirm RT timeout %d msec", dhcp->RT);
-
- dhcp->timeout = g_timeout_add(dhcp->RT, timeout_confirm, dhcp);
-
- g_dhcpv6_client_set_retransmit(dhcp->dhcp_client);
-
- g_dhcp_client_start(dhcp->dhcp_client, NULL);
-
- return FALSE;
-}
-
-static gboolean timeout_max_confirm(gpointer user_data)
-{
- struct connman_dhcpv6 *dhcp = user_data;
-
- dhcp->MRD = 0;
-
- clear_timer(dhcp);
-
- DBG("confirm max retransmit duration timeout");
-
- g_dhcpv6_client_clear_retransmit(dhcp->dhcp_client);
-
- if (dhcp->callback)
- dhcp->callback(dhcp->network, CONNMAN_DHCPV6_STATUS_FAIL,
- NULL);
-
- return FALSE;
-}
-
-static gboolean start_confirm(gpointer user_data)
-{
- struct connman_dhcpv6 *dhcp = user_data;
-
- /* Set the confirm timeout, RFC 3315 chapter 14 */
- dhcp->RT = CNF_TIMEOUT * (1 + get_random());
-
- DBG("confirm initial RT timeout %d msec", dhcp->RT);
-
- dhcp->timeout = g_timeout_add(dhcp->RT, timeout_confirm, dhcp);
- dhcp->MRD = g_timeout_add(CNF_MAX_RD, timeout_max_confirm, dhcp);
-
- dhcpv6_confirm(dhcp);
-
- return FALSE;
-}
-
int __connman_dhcpv6_start(struct connman_network *network,
GSList *prefixes, dhcpv6_cb callback)
{
struct connman_service *service;
- struct connman_ipconfig *ipconfig_ipv6;
struct connman_dhcpv6 *dhcp;
-
Re: [PATCH] service: Fix config file passphrase setting
Hi Patrik,
On ma, 2014-09-08 at 13:38 +0300, Patrik Flykt wrote:
> Create a local passphrase setting function as config files would
> otherwise use the internal passphrase setting function which disallows
> modifications to immutable .config files.
Perhaps it would be more logical to set the immutable flag in config.c
after we have set the passphrase, now it is set before which causes
these problems. Then we do not need to tweak the set passphrase function
at all.
> ---
> src/service.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index d96713d..e6a5240 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -2876,12 +2876,12 @@ static int check_passphrase(enum
> connman_service_security security,
> return 0;
> }
>
> -int __connman_service_set_passphrase(struct connman_service *service,
> - const char *passphrase)
> +static int set_passphrase(struct connman_service *service,
> + const char *passphrase)
> {
> int err;
>
> - if (service->immutable || service->hidden)
> + if (service->hidden)
> return -EINVAL;
>
> err = check_passphrase(service->security, passphrase);
> @@ -2900,6 +2900,15 @@ int __connman_service_set_passphrase(struct
> connman_service *service,
> return 0;
> }
>
> +int __connman_service_set_passphrase(struct connman_service *service,
> + const char *passphrase)
> +{
> + if (service->immutable)
> + return -EINVAL;
> +
> + return set_passphrase(service, passphrase);
> +}
> +
> const char *__connman_service_get_passphrase(struct connman_service *service)
> {
> if (!service)
> @@ -4973,7 +4982,8 @@ void __connman_service_set_string(struct
> connman_service *service,
> g_free(service->phase2);
> service->phase2 = g_strdup(value);
> } else if (g_str_equal(key, "Passphrase"))
> - __connman_service_set_passphrase(service, value);
> + set_passphrase(service, value);
> +
> }
>
> void __connman_service_set_search_domains(struct connman_service *service,
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Fix UTF-8 ssid's
Hi Lorn,
I just wonder what is the issue that this patch is fixing, isn't the
current implementation working?
On pe, 2014-08-01 at 19:42 +1000, Lorn Potter wrote:
> I found an old patch that crashed, and fixed it up.
> Enjoy!
>
> ---
> gsupplicant/supplicant.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
> index 534944b..19dbb1a 100644
> --- a/gsupplicant/supplicant.c
> +++ b/gsupplicant/supplicant.c
> @@ -1256,6 +1256,26 @@ static void
> interface_network_removed(DBusMessageIter *iter, void *user_data)
>
> static char *create_name(unsigned char *ssid, int ssid_len)
> {
> + SUPPLICANT_DBG("%s, %i", ssid, ssid_len)
> +
> + gchar *result;
> + GError *error = 0;
> + gsize bytes_written = 0;
> +
> + if (g_utf8_validate((const char *)ssid, ssid_len, NULL) == TRUE)
> + return g_strndup((const char *)ssid, ssid_len);
> +
> + result = g_convert_with_fallback((const char *)ssid, -1,
> + "UTF-8", "ISO-8859-1",
> + 0, 0,
> + &bytes_written, &error);
SSID's are just byte arrays, how can we know which codeset we are
converting from (you assume ISO-8859-1 here)?
> + if (result) {
> + return result;
> + } else {
> + SUPPLICANT_DBG("Error converting to UTF-8: %s",
> error->message);
> + g_error_free (error);
> + }
> +
> GString *string;
> const gchar *remainder, *invalid;
> int valid_bytes, remaining_bytes;
C++ style code here, the variables should be declared at the beginning
of func.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] dhcp: Fixed Crash on Switching Network
Hi, I see only a .gif in your attachment, perhaps the actual patch is missing? Also please send the patches as inline, you can for example use "git send-email" to send them. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Routing problem
Hi, On 24 July 2014 10:21, G wrote: > Hi folks, > I have a strange bahaviour using connman 1.20 If possible try to upgrade to latest release (1.24), it fixes lot of bugs, although probably does not fix your issue. > > I have a device with an ethernet card and a wifi card > > Both card are with dhcp and are connected to the same network (I know this > is not good, but I can't do in a different way). Furthermore the ethernet > card got a static IP on a different subnet > > So my routing table looks like this > > root@razor:~# ip route > 192.168.10.100 via 192.168.10.100 dev eth0 > 192.168.10.100 dev eth0 scope link > 192.168.10.100 dev wlan0 scope link metric 10 > 10.189.189.0/24 dev eth0 proto kernel scope link src 10.189.189.1 > 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.109 > 192.168.10.0/24 dev wlan0 proto kernel scope link src 192.168.10.107 > metric 10 > 224.0.0.0/24 dev eth0 scope link > default via 192.168.10.100 dev eth0 > > 192.168.10.100 is the dhcp server / default gateway (simply a wireless > router); 10.189.189.0/24 is a control subnet used to reach other devives > through a switch (no VLAN) > > You can see that the route via eth0 is preferred because of a lower metric > > root@razor:~# ip route get 192.168.10.100 > 192.168.10.100 dev eth0 src 192.168.10.109 > cache ipid 0x34b2 mtu 1500 advmss 1460 hoplimit 64 > > The problem arise when I disconnect the ethernet cable, because the routing > table doesn't change at all and if I check the previous route I obtain > > root@razor:~# ip route get 192.168.10.100 > 192.168.10.100 dev eth0 src 10.189.189.1 > cache mtu 1500 advmss 1460 hoplimit 64 > > So the route goes via eth0, using the static configured ip > > The interface looks like this > > root@razor:~# ip link > 1: lo: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: eth0: mtu 1500 qdisc > pfifo_fast state DOWN qlen 1000 > link/ether 00:21:84:30:03:78 brd ff:ff:ff:ff:ff:ff > 3: wlan0: mtu 1500 qdisc mq state UP qlen > 1000 > link/ether 00:21:84:26:01:84 brd ff:ff:ff:ff:ff:ff > > Is this the expected behaviour under these conditions? I tried this setup with my laptop and did not see exacly similar issue (although my ethernet was reconnected to same subnet as wifi). My ethernet got always the default route after toggling ethernet cable. So both ethernet and wifi connected at the same time the routing table looked like this Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.178.1 0.0.0.0 UG0 0 0 em1 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 em1 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp3s0 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 wlp3s0 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 em1 Then after disconnecting ethernet and reconnecting it again I got Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.178.1 0.0.0.0 UG0 0 0 em1 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp3s0 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 em1 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 em1 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 wlp3s0 So the routes are in slightly different order but that does not matter in this case. > > Why routes through eth0 (which is down) aren't removed from routing table? The removal of the eth route seem to have failed (probably because they are in the same subnet as wifi). We should already remove all the routes via some interface when that interface is taken down but this seems to not have happened. I wonder if this could be related to your static IP address for ethernet. Could you try whether the situation changes if you use always dhcp addresses? Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Missing default route after boot
Hi Tobias,
On 24 July 2014 12:44, Tobias Henkel wrote:
> Hi,
>
> I have both ethernet and WIFI connection configured as autoconnect. Further
> connman is configured with SingleConnectedTechnology = true.
The use of SingleConnectedTechnology should be avoided if possible. It
just works too strongly and disconnects the other service even if
someone is using the connection.
Have you tried just to set PreferredTechnologies=ethernet? At least
that setting works in my laptop and only ethernet is normally
connected. I can still manually connect other wifi services and the
ethernet connection would not be disconnected in this case (because I
have SingleConnectedTechnology=false in my conf file).
> Today after boot the ethernet connection was setup with a correct IP address
> (DHCP) but a missing default route. After a restart of connman it was ok
> again. I wasn't able to reproduce this behaviour a second time by rebooting
> or restarting connman.
I have not really seen this behaviour.
>
> Could there be a timing issue when ethernet and WIFI come up at the same
> time when SingleConnectedTechnology is enabled?
Are your ethernet and wifi in the same subnet i.e., are they both in
192.168.0.0/16? If so, that might explain this behaviour.
> I'm using the current master (c1b9fc4) of connman.
>
> Best regards
> Tobias
>
>
> My /etc/connman/main.conf:
> [General]
> PreferredTechnologies = ethernet,wifi
> SingleConnectedTechnology = true
>
> Routing table:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
> 192.168.0.254 0.0.0.0 255.255.255.255 UH0 0 0 eth0
>
> Routing table after connman restart:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> default 192.168.0.254 0.0.0.0 UG0 0 0 eth0
> 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
> 192.168.0.254 0.0.0.0 255.255.255.255 UH0 0 0 eth0
>
> Connman log:
> Jul 24 08:14:50 duffman.bmw-carit.intra connmand[851]: Connection Manager
> version 1.24
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Checking loopback
> interface settings
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: System hostname is
>
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: lo {newlink} index 1
> address 00:00:00:00:00:00 mtu 65536
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: lo {newlink} index 1
> operstate 0
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {create} index 2
> type 1
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags
> 4098
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
> 2 address 10:60:4B:49:47:2E mtu 1500
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
> 2 operstate 2
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Adding interface eth0
> [ ethernet ]
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {create} index 3
> type 1
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
> 4098
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 address 6C:88:14:6E:65:60 mtu 1500
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 operstate 2
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Adding interface wlo1
> [ wifi ]
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags
> 36867
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
> 2 address 10:60:4B:49:47:2E mtu 1500
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
> 2 operstate 2
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Method "ListAdapters"
> with signature "" on interface "org.bluez.Manager" doesn't exist
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
> 4163
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 address 6C:88:14:6E:65:60 mtu 1500
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 operstate 0
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
> 4099
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 address 6C:88:14:6E:65:60 mtu 1500
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 operstate 5
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 address 6C:88:14:6E:65:60 mtu 1500
> Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
> 3 operstate 2
> Jul 24 08:14:52 duffman.bmw-carit.intra connmand[851]: Skipping disconnect
> of 4349543032_managed_psk, network is connecting.
> Jul 24 08:14:54 duffman.bmw-carit.intra conn
Re: fix nfs boot issue from 1.19 to 1.17-reg
Hi, please do not top post in this mailing list. On ke, 2014-07-23 at 11:33 +0530, Kirankumar Bobbu wrote: > HI Juka Rissanen, > > Yes . I agree with ur solution. > But I cant hardcode as " connmand -n -I eth1 " > We may use eth0 or eth1 as nfs n/w interface. > Same service must work for non nfs boot and should manage all n/w interfaces. > > If you have any patch to tweak this in systemd scripts . please provide This systemd tweaking is an distro issue and not part of connman. Please consult your local genivi expert for advice. Cheers, Jukka > > Right now we cant move to 1.24 as I may need recipe file as part of genivi . > That’s grey area for us. > > Best Regards > Kirankumar Bobbu > > > -Original Message- > From: Jukka Rissanen [mailto:jukka.rissa...@linux.intel.com] > Sent: Wednesday, July 23, 2014 11:11 AM > To: connman@connman.net > Cc: Kirankumar Bobbu > Subject: Re: fix nfs boot issue from 1.19 to 1.17-reg > > Hi Kiran, > > On ke, 2014-07-23 at 10:27 +0530, Kirankumar Bobbu wrote: > > Hi, > > > > I am getting the nfs boot issue[ connmand gets down the nfs n/w interface > > ] because of the connman service . ( 1.17 ) as a part of genivi 5.0.2 > > I want to back port the bugfix from 1.19 to 1.17. > > > > I found few patches: > > > > - > > http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=1b87 > > cd7535a360dae57e3238829c91476853af68 > > http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=39a6 > > 8b38aaa3188c3949506083bf469dd87b80f8 > > http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=fd9f > > 99e5320ef904d7fadabdfb401d07eeb3ef26 > > > > Please let me know if am missing something more here? > > Still I am not able to fix the issue. > > Nfs boot use eth1 . > > Try ignoring eth1 so that connman does not touch it and reset it as it is > used for nfs. Just start connman with "connmand -I eth1 ..." > > Also I would recommend that you upgrade to 1.24 if possible, lot of bugs have > been fixed since 1.19. > > Cheers, > Jukka > > > > > --- > This email message is for the sole use of the intended recipient(s) and may > contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact the > sender by > reply email and destroy all copies of the original message. > --- ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: fix nfs boot issue from 1.19 to 1.17-reg
Hi Kiran, On ke, 2014-07-23 at 10:27 +0530, Kirankumar Bobbu wrote: > Hi, > > I am getting the nfs boot issue[ connmand gets down the nfs n/w interface ] > because of the connman service . ( 1.17 ) as a part of genivi 5.0.2 > I want to back port the bugfix from 1.19 to 1.17. > > I found few patches: > > - > http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=1b87cd7535a360dae57e3238829c91476853af68 > http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=39a68b38aaa3188c3949506083bf469dd87b80f8 > http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=fd9f99e5320ef904d7fadabdfb401d07eeb3ef26 > > Please let me know if am missing something more here? > Still I am not able to fix the issue. > Nfs boot use eth1 . Try ignoring eth1 so that connman does not touch it and reset it as it is used for nfs. Just start connman with "connmand -I eth1 ..." Also I would recommend that you upgrade to 1.24 if possible, lot of bugs have been fixed since 1.19. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Fallback AP
Hi Mike,
On ti, 2014-07-22 at 10:29 -0400, Mike Purvis wrote:
> Hey all,
>
> I'm looking for a specific behaviour, and I'm wondering if there's a
> straightforward way for connman to provide it. The behaviour is:
>
>- Attempt to find known AP.
>- Attempt to connect to known AP.
>- After timeout, fall back on hosting on AP ("tethering" in connman
>parlance).
>
ConnMan does not support this in its own, and I think this is better
done outside of ConnMan. So you could have an application doing the
steps you outlined above. The ConnMan dbus API provides means to do
these things.
> There's an example of setting up this pattern using raw
> dnsmasq/wpa_supplicant scripts here
> ,
> but I'm wondering about doing it with connman.
>
> Thoughts?
You could check the python scripts in test directory in ConnMan sources
for examples how to "find known AP" (see test-connman script and search
for "scan"), "connect to known AP" (see test-connman script), "activate
tethering" (see enable-tethering script).
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH v3] scripts: Build libppp-plugin without versioning information
There is no need to have module versioning for libppp-plugin.so file so build the plugin same way as other vpn plugins. This issue was seen when building ConnMan for Yocto. --- Makefile.plugins | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/Makefile.plugins b/Makefile.plugins index 294cae0..e90ad19 100644 --- a/Makefile.plugins +++ b/Makefile.plugins @@ -3,9 +3,6 @@ plugin_cflags = -fvisibility=hidden -I$(srcdir)/gdbus \ @DBUS_CFLAGS@ @GLIB_CFLAGS@ plugin_ldflags = -no-undefined -module -avoid-version -script_cflags = -fvisibility=hidden -I$(srcdir)/gdbus \ - @DBUS_CFLAGS@ - if LOOPBACK builtin_modules += loopback builtin_sources += plugins/loopback.c @@ -156,12 +153,12 @@ endif if PPTP script_LTLIBRARIES += scripts/libppp-plugin.la -scripts_libppp_plugin_la_LDFLAGS = $(script_cflags) @DBUS_CFLAGS@ +scripts_libppp_plugin_la_LDFLAGS = $(plugin_ldflags) scripts_libppp_plugin_la_LIBADD = @DBUS_LIBS@ else if L2TP script_LTLIBRARIES += scripts/libppp-plugin.la -scripts_libppp_plugin_la_LDFLAGS = $(script_cflags) @DBUS_CFLAGS@ +scripts_libppp_plugin_la_LDFLAGS = $(plugin_ldflags) scripts_libppp_plugin_la_LIBADD = @DBUS_LIBS@ endif endif -- 1.8.3.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH v2] scripts: Build libppp-plugin without versioning information
There is no need to have module versioning for libppp-plugin.so file so build the plugin same way as other vpn plugins. This issue was seen when building ConnMan for Yocto. --- Makefile.plugins | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.plugins b/Makefile.plugins index 294cae0..11e3a78 100644 --- a/Makefile.plugins +++ b/Makefile.plugins @@ -156,12 +156,12 @@ endif if PPTP script_LTLIBRARIES += scripts/libppp-plugin.la -scripts_libppp_plugin_la_LDFLAGS = $(script_cflags) @DBUS_CFLAGS@ +scripts_libppp_plugin_la_LDFLAGS = $(plugin_ldflags) scripts_libppp_plugin_la_LIBADD = @DBUS_LIBS@ else if L2TP script_LTLIBRARIES += scripts/libppp-plugin.la -scripts_libppp_plugin_la_LDFLAGS = $(script_cflags) @DBUS_CFLAGS@ +scripts_libppp_plugin_la_LDFLAGS = $(plugin_ldflags) scripts_libppp_plugin_la_LIBADD = @DBUS_LIBS@ endif endif -- 1.8.3.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: tinc
Hi JC, On 21 July 2014 23:07, Jean-Charles Andlauer wrote: > Hello, > > I was wondering if someone already considered managing tinc vpn with connman. I think you are the first one that has asked about tinc in this ml. > > Could anyone recomend me appropriate documentation and samples which could > help me try to implement this? You could check how OpenVPN plugin is implemented (it is actually quite simple). Just check the ConnMan sources at vpn/plugins/openvpn.c for one example. If you need help, just ask on ml or #connman irc channel at freenode. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] scripts: Build libppp-plugin as a plain .so file
There is no need to have module versioning for libppp-plugin.so file so build the plugin same way as other vpn plugins. This issue was seen when building ConnMan for Yocto. --- Makefile.plugins | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.plugins b/Makefile.plugins index 294cae0..8139967 100644 --- a/Makefile.plugins +++ b/Makefile.plugins @@ -4,7 +4,7 @@ plugin_cflags = -fvisibility=hidden -I$(srcdir)/gdbus \ plugin_ldflags = -no-undefined -module -avoid-version script_cflags = -fvisibility=hidden -I$(srcdir)/gdbus \ - @DBUS_CFLAGS@ + @DBUS_CFLAGS@ $(plugin_ldflags) -shared if LOOPBACK builtin_modules += loopback -- 1.8.3.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Reassign best_bss pointer when that bss is removed
Hi Hannu,
On ma, 2014-07-21 at 13:09 +0300, Hannu Mallat wrote:
> When the bss to which best_bss points to is removed, the pointer also
> needs to be reassigned, or reference to already deallocated memory may
> happen later on.
> ---
> gsupplicant/supplicant.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
> index c6342d5..534944b 100644
> --- a/gsupplicant/supplicant.c
> +++ b/gsupplicant/supplicant.c
> @@ -1824,7 +1824,7 @@ static void update_signal(gpointer key, gpointer value,
>
> static void update_network_signal(GSupplicantNetwork *network)
> {
> - if (g_hash_table_size(network->bss_table) <= 1)
> + if (g_hash_table_size(network->bss_table) <= 1 && network->best_bss)
> return;
>
> g_hash_table_foreach(network->bss_table,
> @@ -1837,6 +1837,7 @@ static void interface_bss_removed(DBusMessageIter
> *iter, void *user_data)
> {
> GSupplicantInterface *interface = user_data;
> GSupplicantNetwork *network;
> + struct g_supplicant_bss *bss = NULL;
> const char *path = NULL;
>
> dbus_message_iter_get_basic(iter, &path);
> @@ -1847,6 +1848,12 @@ static void interface_bss_removed(DBusMessageIter
> *iter, void *user_data)
> if (!network)
> return;
>
> + bss = g_hash_table_lookup(network->bss_table, path);
> + if (network->best_bss == bss) {
> + network->best_bss = NULL;
> + network->signal = 0;
> + }
> +
> g_hash_table_remove(bss_mapping, path);
>
> g_hash_table_remove(interface->bss_mapping, path);
Good catch, ACK to this!
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: ever "ready" state
Hi Henrique, On to, 2014-07-17 at 22:35 -0300, Henrique Abreu wrote: > 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? "Ready" state is a good state as is. ConnMan will stay in this state if it for some reason cannot verify internet connection. Why do you insist that you need to be in "Online" state? The internet connection check is done during the service connection phase or if there are multiple services connected at the some time and the other "online" services is disconnected. You cannot manually trigger online check. One typical reason why online check might fail, is that if you are using proxies and your proxy configuration is not correct (either done manually or automatically via pacrunner daemon) 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
Hi Pasi,
On ke, 2014-07-16 at 22:30 +0300, pasi.sjoh...@jolla.com wrote:
> From: Pasi Sjöholm
>
> 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 v4] gdhcp: Request an actual IP address when rebinding
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
