Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: Why can't connman automatically enable and connect to
      cellular network interface? (JH)
   2. Re: Why can't connman automatically enable and connect to
      cellular network interface? (Daniel Wagner)
   3. Re: Why can't connman automatically enable and connect to
      cellular network interface? (JH)
   4. Re: The DHCP/DNS confusion (aka no-one cares about
      /etc/resolv.conf) (Daniel Wagner)
   5. Re: Why can't connman automatically enable and connect to
      cellular network interface? (Daniel Wagner)
   6. Re: [PATCH 5/5] service: Call vpn_auto_connect() when default
      service changes. (Daniel Wagner)
   7. Re: [PATCH v2 0/5] Include VPNs in service.c autoconnect
      process. (Daniel Wagner)
   8. Re: [PATCH 5/5] service: Call vpn_auto_connect() when default
      service changes. (Jussi Laakkonen)


----------------------------------------------------------------------

Message: 1
Date: Thu, 25 Apr 2019 15:41:54 +1000
From: JH <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Christophe Ronco <[email protected]>, [email protected]
Subject: Re: Why can't connman automatically enable and connect to
        cellular network interface?
Message-ID:
        <CAA=hcwqcibz4hbety_69x0l7kcpndm2f4j-tknj_pjfqz0j...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi Daniel,

> While this works for your setup, it has unwanted side effects. Such as
> any new cellular network would autoconnect without interaction of the
> user. Ethernet is different in this regard because the user already told
> use the indent. He plugged the cable into the device.
>
> I am not against changing this stuff, I am just pointing out this needs
> more then just marking the cellular technology per default as auto
> connectable.

What is your recommendation to fix the WiFi and Cellular autoconnect?
The autoconnect is not working, either we are missing something here
in configuration, or it could be bugs?

Thank you.

Kind regards,

- jupiter


------------------------------

Message: 2
Date: Thu, 25 Apr 2019 08:25:57 +0200
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>
Cc: Christophe Ronco <[email protected]>, [email protected]
Subject: Re: Why can't connman automatically enable and connect to
        cellular network interface?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi JH,

On 4/25/19 7:41 AM, JH wrote:
> What is your recommendation to fix the WiFi and Cellular autoconnect?
> The autoconnect is not working, either we are missing something here
> in configuration, or it could be bugs?

I don't think I can't remember your scenario correctly. So you build a 
rootfs which is deployed on embedded boars, right? The device is 
supposed to connect either to WiFi or if that is not available to 
Cellular? For WiFi and Cellular there are provisioning information 
available upfront (user name, password, etc)?

Come to think of it, I am not 100% sure if this works currently without 
code changes. It's one of many different use patterns I haven't really 
tested so far. Given that you are not the first one asking for this kind 
of setup I should try to setup something like this and figure out what 
is not working. More for my todo list...

Obviously, this doesn't help you too much right now. Let me answer your 
other mail. At least there is something you could try out.

Thanks,
Daniel


------------------------------

Message: 3
Date: Thu, 25 Apr 2019 16:51:17 +1000
From: JH <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Christophe Ronco <[email protected]>, [email protected]
Subject: Re: Why can't connman automatically enable and connect to
        cellular network interface?
Message-ID:
        <CAA=hcwsojqk3_vrb8xx0cp3pn8zyprnavd6haylh3sdad4g...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi Daniel,

On 4/25/19, Daniel Wagner <[email protected]> wrote:
> Hi JH,
>
> On 4/25/19 7:41 AM, JH wrote:
>> What is your recommendation to fix the WiFi and Cellular autoconnect?
>> The autoconnect is not working, either we are missing something here
>> in configuration, or it could be bugs?
>
> I don't think I can't remember your scenario correctly. So you build a
> rootfs which is deployed on embedded boars, right? The device is
> supposed to connect either to WiFi or if that is not available to
> Cellular? For WiFi and Cellular there are provisioning information
> available upfront (user name, password, etc)?

Correct, I defined PreferredTechnologies = wifi,cellular in main.conf
to connect to wifi first, if wifi is not available to connect to
cellular running on imx6 EVK.

> Come to think of it, I am not 100% sure if this works currently without
> code changes. It's one of many different use patterns I haven't really
> tested so far. Given that you are not the first one asking for this kind
> of setup I should try to setup something like this and figure out what
> is not working. More for my todo list...

Basically the auto connect does not work. At first time boot up, the
connman does not perform auto connect, I tried to deploy both wifi
(with SSID and Passphrase) and cellular settings to /var/lib/connman,
the connman still could not detect the wifi and cellular until I
perform manual configuration via connmanctl.

> Obviously, this doesn't help you too much right now. Let me answer your
> other mail. At least there is something you could try out.

Unfortunately, I am still learning the connman, cannot make effective
contributions as I like to, but let me know if I can assist for
testing and debugging.

Thank you Daniel,

Kind regards,

- jupiter


------------------------------

Message: 4
Date: Thu, 25 Apr 2019 08:51:57 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: The DHCP/DNS confusion (aka no-one cares about
        /etc/resolv.conf)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Knuth,

On 4/24/19 8:55 PM, [email protected] wrote:
> OK... through the post of Doron Behar "duplicate entries
> in /etc/resolv.conf" I understand now ;)
> 
> But it would really be helpful for others to have "resolv.conf" appear
> in the man page (under FILES) to let people know, that connman actually
> creates a /var/run/connman/resolv.conf ... and this seemingly
> independent of the --nodnsproxy parameter. - Is that correct ?
/var/run/connman/resolv.conf will be created if the directory 
/var/run/connman exists/accessible. And yes, resolv.conf is independent 
of the DNS proxy setting. They are two different things, though related. 
ConnMan write the DNS configuration into resolv.conf. The contents of 
the file is depending on the --nodnsproxy switch.

> Because NetworkManager manipulates /etc/resolv.conf directly and one
> can't guess that there is a /var/run/connman/resolv.conf... or did I
> still miss something ?

IIRC, these days all connection manager will write there resolv.conf 
file into /var/run/$NAME/resolv.conf if told so. The admin just needs to 
symlink /etc/resolv.conf to the resolv.conf he wants. The systemd folks 
have documentation on this (see systemd-resolvd).

> And I can +1 the duplicate entries within /var/run/connman/resolv.conf.
> 'cause mine looks like this:
> 
>       # Generated by Connection Manager
>       search fritz.box fritz.box fritz.box fritz.box fritz.box fritz.box
>       nameserver 192.168.43.1
> 
> Please let me know if you might need additional info in order to
> hunt this bug down.

Thanks for confirming this. It looks like the logic for the filtering 
the nameserver entries is broken. IIRC, we had recently changed the call 
path to address_updates(). Maybe this triggers the entry mess. Just an idea.

Thanks,
Daniel


------------------------------

Message: 5
Date: Thu, 25 Apr 2019 08:56:26 +0200
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>
Cc: Christophe Ronco <[email protected]>, [email protected]
Subject: Re: Why can't connman automatically enable and connect to
        cellular network interface?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 4/25/19 8:51 AM, JH wrote:
> On 4/25/19, Daniel Wagner <[email protected]> wrote:
> Correct, I defined PreferredTechnologies = wifi,cellular in main.conf
> to connect to wifi first, if wifi is not available to connect to
> cellular running on imx6 EVK.

IIRC, there are some products which got this working with ConnMan. So 
not all hope is lost.

> Basically the auto connect does not work. At first time boot up, the
> connman does not perform auto connect, I tried to deploy both wifi
> (with SSID and Passphrase) and cellular settings to /var/lib/connman,
> the connman still could not detect the wifi and cellular until I
> perform manual configuration via connmanctl.

In the other mail you mentioned this. Though looking at the paths/file 
names it looked wrong. The provisioning files life just under 
/var/lib/connman and not in /var/lib/connman/$id/settings. Only files 
under /var/lib/connman/$name.config will be monitored by ConnMan.

Thanks,
Daniel


------------------------------

Message: 6
Date: Thu, 25 Apr 2019 09:05:54 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>, [email protected]
Subject: Re: [PATCH 5/5] service: Call vpn_auto_connect() when default
        service changes.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Jussi,

On 4/23/19 5:22 PM, Jussi Laakkonen wrote:
> This commit adds call to vpn_auto_connect() when default service changes
> and the service is not a VPN service. With this change it is ensured
> that VPNs are being autoconnected when the default network changes.
> ---
>   src/service.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/src/service.c b/src/service.c
> index ea6246d5..50238e3e 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -1594,6 +1594,16 @@ static void default_changed(void)
>               if (service->domainname &&
>                               
> connman_setting_get_bool("AllowDomainnameUpdates"))
>                       __connman_utsname_set_domainname(service->domainname);
> +
> +             /*
> +              * Connect VPN automatically when new default service
> +              * is set and connected, unless new default is VPN
> +              */
> +             if (is_connected(service->state) &&
> +                     service->type != CONNMAN_SERVICE_TYPE_VPN) {
> +                     DBG("running vpn_auto_connect");
> +                     vpn_auto_connect();
> +             }
>       }
>   
>       __connman_notifier_default_changed(service);

This patch doesn't build with patch #3, #4 v2 anymore. Could you send an 
updated version?


Applying: service: Call vpn_auto_connect() when default service changes
  *** .git/hooks/pre-applypatch: Testing for mode changes...
  *** .git/hooks/pre-applypatch: Testing that this is buildable...
make --no-print-directory all-am
   CC       src/connmand-service.o
src/service.c: In function ?default_changed?:
src/service.c:1604:4: warning: implicit declaration of function 
?vpn_auto_connect? [-Wimplicit-function-declaration]
     vpn_auto_connect();
     ^~~~~~~~~~~~~~~~
src/service.c: At top level:
src/service.c:3426:13: warning: conflicting types for ?vpn_auto_connect?
  static void vpn_auto_connect(void);
              ^~~~~~~~~~~~~~~~
src/service.c:3426:13: error: static declaration of ?vpn_auto_connect? 
follows non-static declaration
src/service.c:1604:4: note: previous implicit declaration of 
?vpn_auto_connect? was here
     vpn_auto_connect();
     ^~~~~~~~~~~~~~~~
make[1]: *** [Makefile:3747: src/connmand-service.o] Error 1
make: *** [Makefile:1864: all] Error 2
  *** .git/hooks/pre-applypatch: Didn't pass buildable test


Thanks,
Daniel


------------------------------

Message: 7
Date: Thu, 25 Apr 2019 09:08:06 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>, [email protected]
Subject: Re: [PATCH v2 0/5] Include VPNs in service.c autoconnect
        process.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Jussi,

On 4/24/19 11:46 AM, Jussi Laakkonen wrote:
> Changes since v2:
>   * Patch 0/5: Update "Fourth" description.
>   * Patch 3/5: Remove unnecessary debug logging.
>   * Patch 4/5:
>     * Conform to formatting rules.
>     * Modify comments to be more simple and put more info to commit msg.
>     * Update commit message to be more coherent and understandable.

Patches #1 to #4 applied.

Thanks,
Daniel


------------------------------

Message: 8
Date: Thu, 25 Apr 2019 10:13:24 +0300
From: Jussi Laakkonen <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: [PATCH 5/5] service: Call vpn_auto_connect() when default
        service changes.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Daniel,

On 4/25/19 10:05 AM, Daniel Wagner wrote:
> Hi Jussi,
> 
> On 4/23/19 5:22 PM, Jussi Laakkonen wrote:
>> This commit adds call to vpn_auto_connect() when default service changes
>> and the service is not a VPN service. With this change it is ensured
>> that VPNs are being autoconnected when the default network changes.
>> ---
>> ? src/service.c | 10 ++++++++++
>> ? 1 file changed, 10 insertions(+)
>>
>> diff --git a/src/service.c b/src/service.c
>> index ea6246d5..50238e3e 100644
>> --- a/src/service.c
>> +++ b/src/service.c
>> @@ -1594,6 +1594,16 @@ static void default_changed(void)
>> ????????? if (service->domainname &&
>> ????????????????? connman_setting_get_bool("AllowDomainnameUpdates"))
>> ????????????? __connman_utsname_set_domainname(service->domainname);
>> +
>> +??????? /*
>> +???????? * Connect VPN automatically when new default service
>> +???????? * is set and connected, unless new default is VPN
>> +???????? */
>> +??????? if (is_connected(service->state) &&
>> +??????????? service->type != CONNMAN_SERVICE_TYPE_VPN) {
>> +??????????? DBG("running vpn_auto_connect");
>> +??????????? vpn_auto_connect();
>> +??????? }
>> ????? }
>> ????? __connman_notifier_default_changed(service);
> 
> This patch doesn't build with patch #3, #4 v2 anymore. Could you send an 
> updated version?
> 

Oh, something went wrong in rebasing my local branch then. Sorry about 
this. I'll send updated 4/5 patch soon.

> 
> Applying: service: Call vpn_auto_connect() when default service changes
>  ?*** .git/hooks/pre-applypatch: Testing for mode changes...
>  ?*** .git/hooks/pre-applypatch: Testing that this is buildable...
> make --no-print-directory all-am
>  ? CC?????? src/connmand-service.o
> src/service.c: In function ?default_changed?:
> src/service.c:1604:4: warning: implicit declaration of function 
> ?vpn_auto_connect? [-Wimplicit-function-declaration]
>  ??? vpn_auto_connect();
>  ??? ^~~~~~~~~~~~~~~~
> src/service.c: At top level:
> src/service.c:3426:13: warning: conflicting types for ?vpn_auto_connect?
>  ?static void vpn_auto_connect(void);
>  ???????????? ^~~~~~~~~~~~~~~~
> src/service.c:3426:13: error: static declaration of ?vpn_auto_connect? 
> follows non-static declaration
> src/service.c:1604:4: note: previous implicit declaration of 
> ?vpn_auto_connect? was here
>  ??? vpn_auto_connect();
>  ??? ^~~~~~~~~~~~~~~~
> make[1]: *** [Makefile:3747: src/connmand-service.o] Error 1
> make: *** [Makefile:1864: all] Error 2
>  ?*** .git/hooks/pre-applypatch: Didn't pass buildable test
> 
> 
> Thanks,
> Daniel

Cheers,
Jussi


------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 42, Issue 21
***************************************

Reply via email to