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: IPv6 privacy extensions with connman (Daniel Wagner)
2. Re: Connman API document and test for C / C++ (Daniel Wagner)
3. Re: Huawei ME909s-120 (Daniel Wagner)
4. Re: duplicate entries in /etc/resolv.conf (Daniel Wagner)
5. Re: Why can't connman automatically enable and connect to
cellular network interface? (Daniel Wagner)
6. Re: The DHCP/DNS confusion (aka no-one cares about
/etc/resolv.conf) (Daniel Wagner)
7. Re: [PATCH 0/3] Improve VPN state transitions when
re-connecting (Daniel Wagner)
8. Re: [PATCH 3/5] service: Remove existing VPN auto connect
from main loop. (Daniel Wagner)
9. Re: [PATCH 4/5] service: Implement a do_auto_connect() to
include VPNs in autoconnect. (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Apr 2019 08:53:20 +0200
From: Daniel Wagner <[email protected]>
To: Christian <[email protected]>
Cc: [email protected]
Subject: Re: IPv6 privacy extensions with connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Christian,
On 4/16/19 11:43 AM, Christian wrote:
> I just updated to newer version of libreelec
> (RPi2.arm-devel-20190413210320-#0413-g977b2aa) and this runs connman
> 1.37. If you want to try it yourself, you find it here:
> https://forum.kodi.tv/showthread.php?tid=298461
> However I only saw the version 1.37 in the update notes. Is there a way
> to check the version via connmanctl? I did not see an option.
On startup ConnMan will print the version number. I suppose you will
find in the log files.
> When asking my question, the version must have been at least 1.36 (also
> only derived from libreelec update notes).
>
> Regarding the spelling of preferred, I think any wrong spelling should
> be purged. I know that it is well meant to be fault tolerant, but it is
> massively confusing.
The wrong spelling is not mentioned except for
- IPv6.Privacy: IPv6 privacy option. Value can be either "disabled",
"enabled" or "preferred" (or the misspelled "prefered"). See
use_tempaddr
variable description in Linux kernel
Documentation/networking/ip-sysctl.txt
file.
and the code just excepts 'prefered' as alternative. Whenever we do a
major update we can also drop that part.
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 24 Apr 2019 08:57:46 +0200
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Connman API document and test for C / C++
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 4/17/19 10:02 AM, JH wrote:
> It seems most API documents and test code in test and doc are all
> based on Python program, are there any document / test program based
> on C /C++?
Sure, there are several bindings for ConnMan but I don't in which state
they are. One which is maintained is the one by the mer project:
https://git.merproject.org/mer-core/libconnman-qt/tree/master
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 24 Apr 2019 09:00:25 +0200
From: Daniel Wagner <[email protected]>
To: St?phane David <[email protected]>
Cc: Julien Massot <[email protected]>, [email protected]
Subject: Re: Huawei ME909s-120
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi St?phane,
>> What i'm doing wrong ?
>
> AFAIK Connman is not supposed to deal with cellular interface directly,
> but delegate this task to ofono.
Right, ConnMan uses oFono for cellular devices.
BTW ConnMan 1.33 is pretty old, so if you experience any problems update
first before starting to debug. It might save you a lot of time.
Thanks,
Daniel
------------------------------
Message: 4
Date: Wed, 24 Apr 2019 09:07:13 +0200
From: Daniel Wagner <[email protected]>
To: Doron Behar <[email protected]>
Cc: [email protected]
Subject: Re: duplicate entries in /etc/resolv.conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Doron,
On 4/22/19 1:10 PM, Doron Behar wrote:
> Hello connman devs,
>
> Last update was wonderful - real support for iwd as a WiFi backend is a
> great improvement and as I always say when reporting issues here, it's a
> real pleasure using connman.
>
> The reason I'm posting this thread is because connman does weird things
> with it's /var/run/connman/resolv.conf (which I linked to
> /etc/resolv.conf).
>
> I'm connected both with WiFi and Ethernet to my home network but since
> I've set PreferredTechnologies=ethernet,wifi my default route is through
> the Ethernet connection - exactly as I want it.
Good to hear that this works :)
> I have a few other settings in my /etc/connman/main.conf so perhaps
> they are the reason I'm having trouble with /etc/resolv.conf. Here it
> is:
>
> [General]
> AutoConnectRoamingServices=true
> PersistentTetheringMode=true
> SingleConnectedTechnology=true
> PreferredTechnologies=ethernet,wifi
> AllowDomainnameUpdates=false
> AllowHostnameUpdates=false
>
> The problem I'm having is that I get duplicate entries in
> /etc/resolv.conf, perhaps because I'm connected to the same network
> twice. This is the /etc/resolv.conf connman comes up with whenever I
> boot:
>
> search Home Home Home
> nameserver fdc9:8a32:cbfb:0:16ae:dbff:fe55:f320
> nameserver fdc9:8a32:cbfb:0:16ae:dbff:fe55:f320
> nameserver 192.168.14.1
>
That looks wrong indeed.
> Every once in a while (not only after boot), I need to change
> /etc/resolv.conf to this when I feel the internet becomes slow:
>
> search Home
> nameserver fdc9:8a32:cbfb:0:16ae:dbff:fe55:f320
> nameserver 192.168.14.1
>
> Since the `search` entry seems to be related to my domain, I've added
> AllowDomainnameUpdates=false in order to mitigate that but it doesn't
> help.
Nothing obvious wrong. I'll try to recreate this here.
> Perhaps I don't understand well the configuration file parameters,
> although I've read the manpage thoroughly. Anyway, I think connman
> should avoid writing a `resolv.conf` file with duplicate entries like it
> does to mine.
>
> Waiting for your reply, Thanks.
Thanks for the report. I'll added the task to my todo list.
Thanks,
Daniel
------------------------------
Message: 5
Date: Wed, 24 Apr 2019 09:14:10 +0200
From: Daniel Wagner <[email protected]>
To: Christophe Ronco <[email protected]>
Cc: Tarmo Kuuse <[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/23/19 9:22 AM, Christophe Ronco wrote:
> On 4/21/19 7:56 PM, Tarmo Kuuse wrote:
>> On 21.04.19 10:02, JH wrote:
>>> I installed oFono plugin to an embedded system where the cellular is
>>> used, I suppose that the connman should automatically enable and
>>> connect to cellular when it first time boot up, it didn't, I have to
>>> manually run the connmanctl command to enable and to connect it. In a
>>> product due to limited Flash storage size, I'll not install connmanctl
>>> and there will be no manual interactive process, how can I set up
>>> connman to automatically enable and connect to cellular network
>>> interface?
>>
>> I second this question. With a blank device out of manufacturing, how
>> would I configure connman to automatically bring up the cellular
>> connection? There is no possibility for the user to interact with the
>> device, so cellular should just connect as long as any working SIM is
>> installed. Assume the SIM is 100% good to go - no PIN, APN/user/pass
>> present in mobile-broadband-provider-info, etc.
As it stands today you would deploy a /var/lib/connman/settings with the
correct settings.
> I resolved this problem some time ago by telling that cellular services
> are favorite (like Ethernet services). I use this patch with connman
> 1.36. Here is the patch comment:
>
> ??? [connman] autoconnect cellular service when SIM is not known (#07397)
>
> ??? Add a patch to connnman to make cellular services favorite (like
> ethernet
> ??? services). This allow "unknown" cellular services to be autoconnected.
> ??? Concretely, when a SIM is used for the first time on a board,
> cellular service
> ??? will be autoconnected by connman if there is no ethernet cable
> plugged in.
>
>
> Maybe this could be integrated in upstream connman with a configuration
> in main.conf?
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.
Thanks,
Daniel
------------------------------
Message: 6
Date: Wed, 24 Apr 2019 09:19:26 +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 Tormen,
On 4/23/19 1:57 PM, [email protected] wrote:
> I am having a knot in my brain ;) ... please help:
>
> Who is handeling dhcp requests with connmand?
>
> Now I would have thgought:
> (a) either wpa_supplicant and/or connman
> run dhcpcd or dhclient or pump once a physical layer link is
> established ... and they would update/touch /etc/resolv.conf if they
> received a DNS server via DHCP
>
> (b) or does connmand handles dhcp itself
ConnMan does DHCP itself. No external component involved.
> // But if it's (a):
> I don't see any trace in the log of connmand doing so and
> I just removed /etc/resolv.conf and connected to wifi network and
> no /etc/resolv.conf got created.
>
> // But if it's (b):
> I did not see anything in the log of connmand doing so and
> there seems only the --nodnsproxy parameter... which does
> not help me solve my problem either, because I not want to use
> the internal DNS proxy but still have /etc/resolv.conf
> configured.
IIRC with --nodnsproxy the resolv.conf file should be updated.
> So I am lost.
>
> I am using: /etc/systemd/system/connman.service.d/disable_dns_proxy.conf
> (so connmand is running as `/usr/bin/connmand -n --nodnsproxy`)
>
> Do I then need something like systemd-resolved ??
No needed per se, but you can use systemd-resolved.
> Or maybe I am missing something super obvious ?
>
> It would be helpful if the output of connmand -n would talk about DNS
> server / DHCP / resolv.conf... but if I did not miss it, there was
> nothing.
Try the -d options.
> Reason I am asking: I would like that /etc/resolv.conf get's created
> when connecting (via wpa_supplicant) to wireless network which sends a
> specific DNS server for this wifi network (e.g. for local
> 'login'/'authenication' via web-browser).
>
>
> Thanks a lot for helping me remove the fog I am in :)
With the '-d' options you should get a full log and you might see what
it going on.
Thanks,
Daniel
------------------------------
Message: 7
Date: Wed, 24 Apr 2019 09:26:40 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/3] Improve VPN state transitions when
re-connecting
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jussi,
On 4/23/19 2:53 PM, Jussi Laakkonen wrote:
> This set of patches improves the VPN state transitions when doing a
> cycle of connect -> disconnect -> connect transitions in case
> networking conditions change rapidly. Also cleanup of VPN routes and
> improves as a positive consequence.
>
> First patch forces the VPN provider of connman-vpnd to do full state
> transition in case of re-connection (connect -> ready -> disconnect ->
> idle -> connect). This makes sure that reference counters of the
> provider reach zero and the routes are then removed properly, which
> allows connman to set the interface down as well.
>
> Second patch makes the vpn provider driver to explicitely change the
> state to disconnect when disconnecting a VPN plugin that has no
> disconnect() function implemented or registered as callback.
> Otherwise in such cases the state transition cycle is incomplete,
> e.g., when current network is lost.
>
> Third patch changes the vpn.c vpn_disconnect_check_provider() to call
> disconnection via provider to ensure full state transition cycle.
All three patches applied. Thanks for the excellent commit messages!
Thanks,
Daniel
------------------------------
Message: 8
Date: Wed, 24 Apr 2019 09:34:05 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 3/5] service: Remove existing VPN auto connect
from main loop.
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:
> To ensure better autoconnect for VPNs in case there is a network change
> remove the existing autoconnect from main loop. Otherwise it may be that
> VPN autoconnect would be still running with 10s delays blocking the
> re-connection after new network has become online.
> ---
> src/service.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index 4697b055..388f6134 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -4321,8 +4321,16 @@ out:
>
> static void vpn_auto_connect(void)
> {
> - if (vpn_autoconnect_id)
> - return;
> + /*
> + * Remove existing autoconnect from main loop to reset the attempt
> + * counter in order to get VPN connected when there is a network change.
> + */
> + if (vpn_autoconnect_id) {
> + if (!g_source_remove(vpn_autoconnect_id)) {
> + DBG("cannot remove VPN autoconnect from main loop");
I don't know if we should log this. It is not an error, it's just that
the other code path was faster. What do you think?
> + return;
> + }
> + }
>
> vpn_autoconnect_id =
> g_idle_add(run_vpn_auto_connect, NULL);
>
Thanks,
Daniel
------------------------------
Message: 9
Date: Wed, 24 Apr 2019 09:42:10 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 4/5] service: Implement a do_auto_connect() to
include VPNs in autoconnect.
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 a function to include VPNs in service.c internal
> autoconnect processes. For other than VPN services it calls
> __connman_service_auto_connect(), use of which is replaced with use of
> do_auto_connect() in service.c, and with VPNs vpn_auto_connect() is
> called. Main reason is that VPN autoconnection is not working with
> run_auto_connect() and must be triggered with this kind of approach.
Hmm, I re-read this several times but still don't understand what you
trying to say. Would you mind to try to rewrite this a bit? Thanks!
> For VPNs connection reason has to be set as user/auto. VPNs should not
> be kept reconnecting if the VPN is in failure state, unless the user has
> requested a connection. In case the network conditions cause the failure
> other autoconnection mechanisms do trigger re-connection of VPN, which
> rely on correct state reporting from connman-vpnd.
> ---
> src/service.c | 47 +++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index 388f6134..ea6246d5 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -148,6 +148,7 @@ static struct connman_ipconfig *create_ip4config(struct
> connman_service *service
> static struct connman_ipconfig *create_ip6config(struct connman_service
> *service,
> int index);
> static void dns_changed(struct connman_service *service);
> +static void vpn_auto_connect(void);
>
> struct find_data {
> const char *path;
> @@ -3413,6 +3414,38 @@ error:
> return -EINVAL;
> }
>
> +static void do_auto_connect(struct connman_service *service,
> + enum connman_service_connect_reason reason)
> +{
> + /*
> + * CONNMAN_SERVICE_CONNECT_REASON_NONE must be ignored for VPNs. VPNs
> + * always have reason CONNMAN_SERVICE_CONNECT_REASON_USER/AUTO.
> + */
> + if (!service || (service->type == CONNMAN_SERVICE_TYPE_VPN &&
> + reason == CONNMAN_SERVICE_CONNECT_REASON_NONE))
add an extra tab here, so it doesn't allign with the return.
> + return;
> +
> + /*
> + * Run service auto connect when a service is changed. This is not
> + * needed to be run when VPN service changes, then vpn auto connect is
> + * sufficient.
> + *
> + * Do not run vpn_auto_connect() when VPN entering failure state
> + * triggers this via service_complete() that is called for each service
> + * that is set to failure state in service_indicate_state(). Otherwise
> + * the timeout of vpn_auto_connect() will be reset and the delays for
> + * VPN connections are reset likewise. User request should reset the
> + * timer.
> + */
I think it would be better to move this info into the commit message,
because it refernces a lot of other code places. This tends to go stale
after a while because no one is updating comments.
> + if (service->type != CONNMAN_SERVICE_TYPE_VPN)
> + __connman_service_auto_connect(reason);
> + else if (service->state == CONNMAN_SERVICE_STATE_FAILURE &&
> + reason != CONNMAN_SERVICE_CONNECT_REASON_USER)
> + return;
> +
> + vpn_auto_connect();
> +}
> +
> int __connman_service_reset_ipconfig(struct connman_service *service,
> enum connman_ipconfig_type type, DBusMessageIter *array,
> enum connman_service_state *new_state)
> @@ -3477,7 +3510,7 @@ int __connman_service_reset_ipconfig(struct
> connman_service *service,
> settings_changed(service, new_ipconfig);
> address_updated(service, type);
>
> -
> __connman_service_auto_connect(CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> + do_auto_connect(service, CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> }
>
> DBG("err %d ipconfig %p type %d method %d state %s", err,
> @@ -3555,7 +3588,8 @@ static DBusMessage *set_property(DBusConnection *conn,
> autoconnect_changed(service);
>
> if (autoconnect)
> -
> __connman_service_auto_connect(CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> + do_auto_connect(service,
> + CONNMAN_SERVICE_CONNECT_REASON_AUTO);
>
> service_save(service);
> } else if (g_str_equal(name, "Nameservers.Configuration")) {
> @@ -3881,7 +3915,7 @@ static void service_complete(struct connman_service
> *service)
> reply_pending(service, EIO);
>
> if (service->connect_reason != CONNMAN_SERVICE_CONNECT_REASON_USER)
> - __connman_service_auto_connect(service->connect_reason);
> + do_auto_connect(service, service->connect_reason);
>
> g_get_current_time(&service->modified);
> service_save(service);
> @@ -4433,7 +4467,7 @@ static gboolean connect_timeout(gpointer user_data)
> if (autoconnect &&
> service->connect_reason !=
> CONNMAN_SERVICE_CONNECT_REASON_USER)
> -
> __connman_service_auto_connect(CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> + do_auto_connect(service, CONNMAN_SERVICE_CONNECT_REASON_AUTO);
>
> return FALSE;
> }
> @@ -5937,7 +5971,7 @@ static int service_indicate_state(struct
> connman_service *service)
> */
> downgrade_connected_services();
>
> -
> __connman_service_auto_connect(CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> + do_auto_connect(service, CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> break;
>
> case CONNMAN_SERVICE_STATE_FAILURE:
> @@ -7288,7 +7322,8 @@ struct connman_service *
> __connman_service_create_from_network(struct connman_ne
> case CONNMAN_SERVICE_TYPE_VPN:
> case CONNMAN_SERVICE_TYPE_WIFI:
> case CONNMAN_SERVICE_TYPE_CELLULAR:
> -
> __connman_service_auto_connect(CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> + do_auto_connect(service,
> + CONNMAN_SERVICE_CONNECT_REASON_AUTO);
> break;
> }
> }
>
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 42, Issue 18
***************************************
