Re: [RFC 3/5] resolver: Create STATEDIR and use it when writing resolv.conf

[Jukka Rissanen]

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

[Jukka Rissanen]

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
> <jukka.rissa...@linux.intel.com> 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
> <patrik.fl...@linux.intel.com>
> > wrote:
> >
> > >
> > > Hi,
> > >
> > > On Wed, 2015-09-30 at 22:08 -0700, Naveen Singh wrote:
> > > > From: Naveen Singh <nav...@nestlabs.com>
> > > >
> > > > 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
>

Re: [PATCH] IPv6 Timeserver for NTP

[Jukka Rissanen]

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(, 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(, 0, sizeof(in4addr));
> > > + in4addr.sin_family = AF_INET;
> > > + in4addr.sin_port = htons(123);
> > > + size = sizeof(in4addr);
> > > + addrptr = (unsigned char *)_addr.s_addr;
> > > + addr = (struct sockaddr *)
> > > + } else if (family == AF_INET6){
> > > + memset(, 0, sizeof(in6addr));
> > > + in6addr.sin6_family = 

Re: Connman

[Jukka Rissanen]

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] ntp: Fix print format for timeval and make debug output more informative

[Jukka Rissanen]

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 v1 3/4] firewall: Add support for single rule add/remove operations

[Jukka Rissanen]

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-rule_spec);
 - if (err  0) {
 - connman_error(Cannot remove previously installed 
 - iptables rules: %s, strerror(-err));
 - 

Re: [PATCH] dnsproxy: Fix spelling of refreshing in debug message

[Jukka Rissanen]

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

[Jukka Rissanen]

Hi Peter,

On ma, 2015-07-27 at 17:45 +0200, Peter Meerwald wrote:
 From: Peter Meerwald p.meerw...@bct-electronic.com
 
 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 1/2] config: monitor inotify event IN_MOVED_FROM

[Jukka Rissanen]

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] vpn: Fix NULL dereferencing in vpn_set_state

[Jukka Rissanen]

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

Re: [PATCH] doc: Update service documentation about Immutable

[Jukka Rissanen]

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 v0 1/4] session_policy_local: Set defaults when using policy file

[Jukka Rissanen]

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 v0 3/4] firewall: Add support for single rule add/remove operations

[Jukka Rissanen]

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)) {
   rule = list-data;
  
 - err = delete_managed_rule(rule-table,
 - rule-chain, rule-rule_spec);
 - if (err  0) {
 -  

Re: Seeing issues with NTP

[Jukka Rissanen]

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] doc: Clarify the VPN routes description for IPv6

[Jukka Rissanen]

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

[PATCH 5/6] vpn: Set disconnected VPN service to IDLE

[Jukka Rissanen]

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 2/6] vpn: NULL dbus message in plugin input handler

[Jukka Rissanen]

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 4/6] vpn: Pass original sender to connman-vpnd when connecting

[Jukka Rissanen]

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(struct connman_provider 

[PATCH 6/6] vpn: Provider state was not updated after an error

[Jukka Rissanen]

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 1/6] agent: Do not access NULL pointer in cancelling

[Jukka Rissanen]

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

[Jukka Rissanen]

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 0/6] VPN fixes

[Jukka Rissanen]

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 v2 0/6] Strip whitespace and empty strings from DBus input

[Jukka Rissanen]

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: [PATCH] doc/technology-api.txt: Fix typo

[Jukka Rissanen]

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: cellular technology is not getting listed

[Jukka Rissanen]

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 3/5] service: Remove empty strings from Proxy

[Jukka Rissanen]

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

[Jukka Rissanen]

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: [PATCH v2 0/6] Strip whitespace and empty strings from DBus input

[Jukka Rissanen]

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: connman online test

[Jukka Rissanen]

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

[Jukka Rissanen]

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: Disable rp_filter in main.conf

[Jukka Rissanen]

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 
 jukka.rissa...@linux.intel.commailto: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?

[Jukka Rissanen]

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

[Jukka Rissanen]

Hi Pasi,

On ke, 2015-05-06 at 14:22 +0300, pasi.sjoh...@jolla.com wrote:
 From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
 
 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

[Jukka Rissanen]

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

[PATCH] wifi: Do not add frequency to hidden AP scan

[Jukka Rissanen]

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.

[Jukka Rissanen]

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

Re: Hidden network with different APs.

[Jukka Rissanen]

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.

[Jukka Rissanen]

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.

[Jukka Rissanen]

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

Re: [PATCH] dnsproxy: request_data in request_list need the request data

[Jukka Rissanen]

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

[RFC 2/3] dnsproxy: Do not check numserv in request timeout

[Jukka Rissanen]

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 0/3] DNS proxy fixes

[Jukka Rissanen]

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

[Jukka Rissanen]

From: Slava Monich slava.mon...@jolla.com

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

[PATCH] configure: Add option to set path of the pptp binary

[Jukka Rissanen]

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

[Jukka Rissanen]

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] plugin: vlan: add support for VLAN

[Jukka Rissanen]

Hi Marcus,

On ti, 2015-03-31 at 20:08 +0200, Marcus Folkesson wrote:
 From: Marcus Folkesson marcus.folkes...@gmail.com
 
 Support for multiple VLANs binded to the same interface.
 VLAN services appear as:
   vlan_MAC to bounded IF_VLAN IFNAME
 For example:
   vlan_5c260a4bf6a3_vlan3
 
 Signed-off-by: Marcus Folkesson marcus.folkes...@gmail.com
 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

[Jukka Rissanen]

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: [PATCH] device/inet: Create read-only devices instead of ignoring completely

[Jukka Rissanen]

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: connman connection policy

[Jukka Rissanen]

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,
 Ram
 


Jukka


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

Re: connman connection policy

[Jukka Rissanen]

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

[Jukka Rissanen]

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:
 
 *   name-hiddenwifi_28b2bda10ba8_hidden_managed_psk
 *A  name-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

[Jukka Rissanen]

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)
   goto err;
  
 - network-connecting = false;
 -
 - connman_network_set_associating(network, false);
 -
 - return;
 -
  err:
 - 

Re: [PATCH] Add setting: UpdateResolvConf

[Jukka Rissanen]

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

[Jukka Rissanen]

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

[Jukka Rissanen]

Hi Vasiliy,

On ke, 2015-01-28 at 13:51 +0400, Vasiliy Tolstov wrote:
 2015-01-12 12:07 GMT+03:00 Tomasz Bursztyka 
 tomasz.burszt...@linux.intel.com:
  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

[Jukka Rissanen]

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

[Jukka Rissanen]

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

Re: [PATCH 3/6] ofono: Old nameservers need to be cleared

[Jukka Rissanen]

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

[Jukka Rissanen]

On to, 2014-12-11 at 12:24 +0200, Tomasz Bursztyka wrote:
 Hi,
 
 NACK.
 
  From: Chengyi Zhao chengyi1.z...@archermind.com
 
  ---
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: connman not bringing up interfaces

[Jukka Rissanen]

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

[Jukka Rissanen]

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

[Jukka Rissanen]

Hi Pasi,

On su, 2014-10-19 at 00:33 +0300, pasi.sjoh...@jolla.com wrote:
 From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
 
 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

[Jukka Rissanen]

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: Connman refusing to find wifi

[Jukka Rissanen]

Hi Matti,

On 13 October 2014 21:23, Matti Laakso malaa...@elisanet.fi 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: [PATCH] dnxproxy: Enable DNS on non-default services if there is no default

[Jukka Rissanen]

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 jmaggar...@gmail.com
 ---
  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)

[Jukka Rissanen]

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

Re: Connman tethering landing page (or single dns record pointing back to itself)

[Jukka Rissanen]

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

[PATCH v2] gdhcp: Workaround for buggy AP that handle broadcast flag incorrectly

[Jukka Rissanen]

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,
+   dst_addr);
   

Re: Connman behavior with marginally stabe wifi

[Jukka Rissanen]

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 1/4] gdhcp: Transaction id was not set when receiving L2 packet

[Jukka Rissanen]

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/4] gdhcp: Transaction id is in network byte order

[Jukka Rissanen]

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 0/4] Misc DHCPv4 patches

[Jukka Rissanen]

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 3/4] gdhcp: Fix memory leak when clearing option hash

[Jukka Rissanen]

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] Fix fallback nameservers harder

[Jukka Rissanen]

From: Andreas Hartmetz ahartm...@gmail.com

- 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 0/2] IPv6 ipconfig fixes

[Jukka Rissanen]

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 2/2] ipconfig: Do not disable kernel IPv6 support when disabling ipconfig

[Jukka Rissanen]

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 arjunas...@gmail.com 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

[Jukka Rissanen]

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] dhcpv6: Remove CONFIRM message sending when connecting a link

[Jukka Rissanen]

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;
-   char *last_address;
int 

Re: [PATCH] service: Fix config file passphrase setting

[Jukka Rissanen]

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

[Jukka Rissanen]

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

[Jukka Rissanen]

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: Missing default route after boot

[Jukka Rissanen]

Hi Tobias,

On 24 July 2014 12:44, Tobias Henkel tobias.hen...@oss.bmw-carit.de 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 UNKNOWN
 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {create} index 2
 type 1 ETHER
 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags
 4098 DOWN
 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 DOWN
 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 ETHER
 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
 4098 DOWN
 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 DOWN
 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 UP
 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 DOWN
 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 UP,RUNNING
 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 UNKNOWN
 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
 4099 UP
 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 DORMANT
 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 DOWN
 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 

Re: Routing problem

[Jukka Rissanen]

Hi,

On 24 July 2014 10:21, G i...@asidev.com 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: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP 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: BROADCAST,MULTICAST,UP,LOWER_UP 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: fix nfs boot issue from 1.19 to 1.17-reg

[Jukka Rissanen]

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

[PATCH v2] scripts: Build libppp-plugin without versioning information

[Jukka Rissanen]

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

[PATCH v3] scripts: Build libppp-plugin without versioning information

[Jukka Rissanen]

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

Re: Fallback AP

[Jukka Rissanen]

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
 http://wiki.ros.org/turtlebot/Tutorials/Advanced%20Networking%20Setup#Fallback_to_AdHoc_Networking,
 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

Re: fix nfs boot issue from 1.19 to 1.17-reg

[Jukka Rissanen]

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: [PATCH] gsupplicant: Reassign best_bss pointer when that bss is removed

[Jukka Rissanen]

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

[PATCH] scripts: Build libppp-plugin as a plain .so file

[Jukka Rissanen]

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: tinc

[Jukka Rissanen]

Hi JC,

On 21 July 2014 23:07, Jean-Charles Andlauer andla...@gmail.com 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

Re: ever ready state

[Jukka Rissanen]

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 v3] service: Changes to favorite property also affect the autoconnect property.

[Jukka Rissanen]

Hi Aaron,

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

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


Cheers,
Jukka


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

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

[Jukka Rissanen]

Hi Justin,

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

Ack to this, looks good now.


Cheers,
Jukka


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

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

[Jukka Rissanen]

Hi Pasi,

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

The numbers look sane, ACK to this.


Cheers,
Jukka


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

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

[Jukka Rissanen]

Hi Tomasz,

On ke, 2014-07-16 at 16:17 +0300, Tomasz Bursztyka wrote:
 This will finally handle the default case when our local device ends up
 as the P2P group owner and thus needs to be the dhcp server as well.
 ---
  src/peer.c | 145 
 -
  1 file changed, 134 insertions(+), 11 deletions(-)
 
 diff --git a/src/peer.c b/src/peer.c
 index 3a6f178..ff5483c 100644
 --- a/src/peer.c
 +++ b/src/peer.c
 @@ -25,6 +25,7 @@
  
  #include errno.h
  #include gdbus.h
 +#include gdhcp/gdhcp.h
  
  #include connman.h
  
 @@ -52,8 +53,12 @@ struct connman_peer {
   DBusMessage *pending;
   bool registered;
   bool connection_master;
 + struct connman_ippool *ip_pool;
 + GDHCPServer *dhcp_server;
  };
  
 +static void stop_dhcp_server(struct connman_peer *peer);

Do we need forward declaration here? It looks like the
stop_dhcp_server() could be put here instead?

 +
  static void reply_pending(struct connman_peer *peer, int error)
  {
   if (!peer-pending)
 @@ -83,6 +88,8 @@ static void peer_free(gpointer data)
   peer-ipconfig = NULL;
   }
  
 + stop_dhcp_server(peer);
 +
   if (peer-device) {
   connman_device_unref(peer-device);
   peer-device = NULL;
 @@ -341,11 +348,14 @@ static int peer_disconnect(struct connman_peer *peer)
  
   reply_pending(peer, ECONNABORTED);
  
 + if (peer-connection_master)
 + stop_dhcp_server(peer);
 + else
 + __connman_dhcp_stop(peer-ipconfig);
 +
   if (peer_driver-disconnect)
   err = peer_driver-disconnect(peer);
  
 - __connman_dhcp_stop(peer-ipconfig);
 -
   return err;
  }
  
 @@ -493,6 +503,99 @@ void connman_peer_set_as_master(struct connman_peer 
 *peer, bool master)
   peer-connection_master = master;
  }
  
 +static void stop_dhcp_server(struct connman_peer *peer)
 +{
 + DBG();
 +
 + if (peer-dhcp_server) {
 + g_dhcp_server_stop(peer-dhcp_server);
 + g_dhcp_server_unref(peer-dhcp_server);
 + }
 + peer-dhcp_server = NULL;
 +
 + if (peer-ip_pool)
 + __connman_ippool_unref(peer-ip_pool);
 + peer-ip_pool = NULL;
 +}

Moving this before reply_pending()?

 +
 +static void dhcp_server_debug(const char *str, void *data)
 +{
 + connman_info(%s: %s\n, (const char *) data, str);
 +}
 +
 +static gboolean dhcp_server_started(gpointer data)
 +{
 + struct connman_peer *peer = data;
 +
 + connman_peer_set_state(peer, CONNMAN_PEER_STATE_READY);

What happens if this was last ref to peer and it is removed at this
point? Will the dhcp server be still active?

 + connman_peer_unref(peer);
 +
 + return FALSE;
 +}
 +
 +static int start_dhcp_server(struct connman_peer *peer)
 +{
 + const char *start_ip, *end_ip;
 + GDHCPServerError dhcp_error;
 + const char *broadcast;
 + const char *gateway;
 + const char *subnet;
 + int prefixlen;
 + int index;
 + int err;
 +
 + DBG();
 +
 + err = -ENOMEM;
 +
 + if (peer-sub_device)
 + index = connman_device_get_index(peer-sub_device);
 + else
 + index = connman_device_get_index(peer-device);
 +
 + peer-ip_pool = __connman_ippool_create(index, 2, 1, NULL, NULL);

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

 + if (!peer-ip_pool)
 + goto error;
 +
 + gateway = __connman_ippool_get_gateway(peer-ip_pool);
 + subnet = __connman_ippool_get_subnet_mask(peer-ip_pool);
 + broadcast = __connman_ippool_get_broadcast(peer-ip_pool);
 + start_ip = __connman_ippool_get_start_ip(peer-ip_pool);
 + end_ip = __connman_ippool_get_end_ip(peer-ip_pool);
 +
 + prefixlen = connman_ipaddress_calc_netmask_len(subnet);
 +
 + err = __connman_inet_modify_address(RTM_NEWADDR,
 + NLM_F_REPLACE | NLM_F_ACK, index, AF_INET,
 + gateway, NULL, prefixlen, broadcast);
 + if (err  0)
 + goto error;
 +
 + peer-dhcp_server = g_dhcp_server_new(G_DHCP_IPV4, index, dhcp_error);
 + if (!peer-dhcp_server)
 + goto error;
 +
 + g_dhcp_server_set_debug(peer-dhcp_server,
 + dhcp_server_debug, Peer DHCP server);
 + g_dhcp_server_set_lease_time(peer-dhcp_server, 3600);
 + g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_SUBNET, subnet);
 + g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_ROUTER, gateway);
 + g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_DNS_SERVER, NULL);
 + g_dhcp_server_set_ip_range(peer-dhcp_server, start_ip, end_ip);
 +
 + err = g_dhcp_server_start(peer-dhcp_server);
 + if (err  0)
 + goto error;
 +
 + g_timeout_add_seconds(0, dhcp_server_started, connman_peer_ref(peer));
 +
 + return 0;
 +
 +error:
 + stop_dhcp_server(peer);
 + return err;
 +}
 +
  static void dhcp_callback(struct connman_ipconfig 

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

[Jukka Rissanen]

Hi Tomasz,

On ke, 2014-07-16 at 16:17 +0300, Tomasz Bursztyka wrote:
 It does not rely here on an ipconfig in the contrary to the dhcp client,
 so it will get the settings from the underneath dhcpv4 server.

I have some difficulty understanding the explanation above. Is it
possible to re-phrase the sentence?

 ---
  src/peer.c | 28 ++--
  1 file changed, 26 insertions(+), 2 deletions(-)
 
 diff --git a/src/peer.c b/src/peer.c
 index ff5483c..25b942f 100644
 --- a/src/peer.c
 +++ b/src/peer.c
 @@ -150,14 +150,38 @@ static bool allow_property_changed(struct connman_peer 
 *peer)
   return true;
  }
  
 +static void append_dhcp_server_ipv4(DBusMessageIter *iter, void *user_data)
 +{
 + struct connman_peer *peer = user_data;
 + const char *str = dhcp;
 + const char *gateway;
 + const char *subnet;
 +
 + if (!peer-ip_pool)
 + return;
 +
 + gateway = __connman_ippool_get_gateway(peer-ip_pool);
 + subnet = __connman_ippool_get_subnet_mask(peer-ip_pool);
 +
 + connman_dbus_dict_append_basic(iter, Method, DBUS_TYPE_STRING, str);
 + connman_dbus_dict_append_basic(iter, Address,
 + DBUS_TYPE_STRING, gateway);
 + connman_dbus_dict_append_basic(iter, Netmask,
 + DBUS_TYPE_STRING, subnet);
 + connman_dbus_dict_append_basic(iter, Gateway,
 + DBUS_TYPE_STRING, gateway);
 +}
 +
  static void append_ipv4(DBusMessageIter *iter, void *user_data)
  {
   struct connman_peer *peer = user_data;
  
 - if (peer-state != CONNMAN_PEER_STATE_READY)
 + if (!is_connected(peer))
   return;
  
 - if (peer-ipconfig)
 + if (peer-connection_master)
 + append_dhcp_server_ipv4(iter, peer);
 + else if (peer-ipconfig)
   __connman_ipconfig_append_ipv4(peer-ipconfig, iter);
  }
  


Cheers,
Jukka


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

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

[Jukka Rissanen]

Hi Tomasz,

Could the patch #2 be put before this patch so the helper function
definition would be nearer to this one?

On ke, 2014-07-16 at 16:27 +0300, Tomasz Bursztyka wrote:
 This will let peer core starting dhcp either as a server or as a client.
 ---
  plugins/wifi.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/plugins/wifi.c b/plugins/wifi.c
 index ba4ce66..eb1fad0 100644
 --- a/plugins/wifi.c
 +++ b/plugins/wifi.c
 @@ -2373,6 +2373,8 @@ static void peer_changed(GSupplicantPeer *peer,
   if (!g_wifi)
   return;
  
 + connman_peer_set_as_master(connman_peer,
 + !g_supplicant_peer_is_client(peer));

This function name is a bit confusing as it only sets the master role if
parameter is true. Perhaps connman_peer_set_role() or similar. Not a big
issue thou, you decide.

   connman_peer_set_sub_device(connman_peer, g_wifi-device);
   }
  


Cheers,
Jukka


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

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

[Jukka Rissanen]

On ti, 2014-07-15 at 10:07 +0300, Tomasz Bursztyka wrote:
 Hi,
 
 NACK to this patch. It's complicated and creates too much inter-dependencies
 between Favorite and Autoconnect.
 
 Imho, when setting Favorite to False, service-autoconnect should be set 
 to false as well.
 After all, when calling Remove() user don't expect to be able to tweak 
 anything anymore on
 that service and of course not to be able to connect it, thus it's fair 
 to get all this basic
 setting going to default.

There is an issue with this also. If user sets favorite to false and
then reconnects to it, the previous value (which might have been tweaked
by user earlier) to autoconnect flag is lost.

While the service is removed when favorite is set to false, the service
is not removed from disk and if user manually re-connects to it, all the
user set options are preserved.


Cheers,
Jukka


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

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

[Jukka Rissanen]

Hi Aaron,

On ti, 2014-07-15 at 10:28 +1000, Aaron McCarthy wrote:
 On Mon, 14 Jul 2014 11:20:39 Jukka Rissanen wrote:
  On ma, 2014-07-14 at 10:45 +1000, Aaron McCarthy wrote:
   The AutoConnect property is always reported as false if Favorite is
   false. Emit property changed for AutoConnect when Favorite changes.
   ---
   
src/service.c | 3 +++
1 file changed, 3 insertions(+)
   
   diff --git a/src/service.c b/src/service.c
   index 9406bc3..899f981 100644
   --- a/src/service.c
   +++ b/src/service.c
   @@ -4885,6 +4885,9 @@ int __connman_service_set_favorite_delayed(struct
   connman_service *service, 
 favorite_changed(service);
   
   + if (service-autoconnect)
   + autoconnect_changed(service);
   +
  
  There is a problem here. If we set the Favorite to false and if
  autoconnect is still true, then a signal would be set that tells that
  service autoconnect is still true. But we will never autoconnect to this
  service in this case because it is not favorite any more.
  
  What kind of use case you had in mind here?
  Why is it not enough to follow the favorite flag?
 
 The problem is that we are displaying the state of the AutoConnect property 
 in 
 the UI. The application is watching for property changes for a particular 
 service. When the Favorite property changes (causing a corresponding change 
 to 
 AutoConnect) the application gets notified of the Favorite property change 
 but 
 not the AutoConnect property change. Explicitly requesting the value of the 
 AutoConnect property returns the expected value.
 

As a Jolla phone user, I must say that the connectivity UI would need a
complete overhaul. Toggling autoconnect flag in main wlan menu does not
make much sense. This is probably not a proper forum for that discussion
so I do not go there.

 On further investigation the AutoConnect value reported by the DBus 
 GetProperties method and autoconnect_changed() are different when Favorite is 
 false. I've fixed the patch so that the value reported by both are the same.
 

Cheers,
Jukka


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