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? (Christophe Ronco)
2. The DHCP/DNS confusion (aka no-one cares about
/etc/resolv.conf) ([email protected])
3. [PATCH 0/3] Improve VPN state transitions when re-connecting
(Jussi Laakkonen)
4. [PATCH 1/3] vpn: Let previous connection to finish before
starting new one. (Jussi Laakkonen)
5. [PATCH 2/3] vpn: Set provider state to disconnect if driver
has no disconnect impl. (Jussi Laakkonen)
6. [PATCH 3/3] vpn: Disconnect via provider when transport is
gone or not valid. (Jussi Laakkonen)
7. [PATCH 0/5] Include VPNs in service.c autoconnect process.
(Jussi Laakkonen)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Apr 2019 09:22:42 +0200
From: Christophe Ronco <[email protected]>
To: 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"
Hi,
On 4/21/19 7:56 PM, Tarmo Kuuse wrote:
> Hi!
>
> 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.
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?
Best Regards,
Christophe Ronco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-service-cellular-services-are-favorite.patch
Type: text/x-patch
Size: 477 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20190423/804b4ec1/attachment-0001.patch>
------------------------------
Message: 2
Date: Tue, 23 Apr 2019 13:57:53 +0200
From: <[email protected]>
To: [email protected]
Subject: The DHCP/DNS confusion (aka no-one cares about
/etc/resolv.conf)
Message-ID: <20190423135606.0a14a9b7@huit>
Content-Type: text/plain; charset=US-ASCII
Hi,
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
// 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.
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 ??
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.
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 :)
Tormen
------------------------------
Message: 3
Date: Tue, 23 Apr 2019 15:53:25 +0300
From: Jussi Laakkonen <[email protected]>
To: [email protected]
Subject: [PATCH 0/3] Improve VPN state transitions when re-connecting
Message-ID: <[email protected]>
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.
Jussi Laakkonen (3):
vpn: Let previous connection to finish before starting new one.
vpn: Set provider state to disconnect if driver has no disconnect
impl.
vpn: Disconnect via provider when transport is gone or not valid.
plugins/vpn.c | 5 +++--
vpn/plugins/vpn.c | 7 +++++++
vpn/vpn-provider.c | 25 ++++++++++++++++++++++++-
3 files changed, 34 insertions(+), 3 deletions(-)
--
2.20.1
------------------------------
Message: 4
Date: Tue, 23 Apr 2019 15:53:26 +0300
From: Jussi Laakkonen <[email protected]>
To: [email protected]
Subject: [PATCH 1/3] vpn: Let previous connection to finish before
starting new one.
Message-ID: <[email protected]>
If a provider is being re-used for a VPN connection in case of
re-connection when network changes happen rapidly it is imperative to
let the provider to finish the previous connection properly. If the
provider is being disconnected, let caller know that transition is in
progress. Do the same if the last connection failed but first, do a
state state transition to idle to allow the failed connection to finish
as well.
Otherwise the reference counters are never decreased as provider goes
from disconnect/failure/ready -> connect and the old interface will
be still up. Also the routes of that interface will remain in routing
table. Until the VPN is re-connected for the second time and interface
is re-used the interface and routes will remain. This happens because
the vpn_exit() is called after the VPN has been re-connected in most
cases and when there is a reference existing, contents are not cleared
and routes are not freed, keeping the interface also up.
This commit naturally makes the re-connection a bit slower as the state
transition must finish first. The issue described happens usually when
dropping out from WiFi after hopping between 2 or more WiFi networks and
using a fallback connection (mobile data, ethernet) and the VPN gets
re-connected immediatelly after the change of network is detected.
The scenario is usually:
1) When connected to WiFi A connect manually to WiFi B
2) Let VPN connect using WiFi B
3) Shutdown WiFi B after VPN has connected
4) Let to switch to other network type (e.g, mobile data, ethernet)
5) Let VPN to autoconnect using the network type used
6) Let to automatically connect to WiFi A and to establish new VPN conn.
7) There are 2 vpn adapters up with stale routes of the old adapter
---
vpn/vpn-provider.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
index dd54ac08..c3df20b0 100644
--- a/vpn/vpn-provider.c
+++ b/vpn/vpn-provider.c
@@ -1098,7 +1098,30 @@ int __vpn_provider_connect(struct vpn_provider
*provider, DBusMessage *msg)
{
int err;
- DBG("provider %p", provider);
+ DBG("provider %p state %d", provider, provider->state);
+
+ switch (provider->state) {
+ /*
+ * When previous connection has failed change state to idle and let
+ * the connmand to process this information as well. Return -EINPROGRESS
+ * to indicate that transition is in progress and next connection
+ * attempt will continue as normal.
+ */
+ case VPN_PROVIDER_STATE_FAILURE:
+ vpn_provider_set_state(provider, VPN_PROVIDER_STATE_IDLE);
+ /*
+ * If re-using a provider and it is being disconnected let it finish
+ * the disconnect process in order to let vpn.c:vpn_died() to get
+ * processed and everything cleaned up. Otherwise the reference
+ * counters are not decreased properly causing the previous interface
+ * being left up and its routes will remain in routing table. Return
+ * -EINPROGRESS to indicate that transition is in progress.
+ */
+ case VPN_PROVIDER_STATE_DISCONNECT:
+ return -EINPROGRESS;
+ default:
+ break;
+ }
if (provider->driver && provider->driver->connect) {
const char *dbus_sender = dbus_message_get_sender(msg);
--
2.20.1
------------------------------
Message: 5
Date: Tue, 23 Apr 2019 15:53:27 +0300
From: Jussi Laakkonen <[email protected]>
To: [email protected]
Subject: [PATCH 2/3] vpn: Set provider state to disconnect if driver
has no disconnect impl.
Message-ID: <[email protected]>
This commit adds setting of provider state to disconnect when the driver
has no disconnect() function implemented. This is imperative to do in a
scenario when network conditions change rapidly and VPN is being
re-connected. This ensures the state transition from ready to disconnect
in such case when VPN driver does not have the functionality implemented
to indicate state transition.
---
vpn/plugins/vpn.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/vpn/plugins/vpn.c b/vpn/plugins/vpn.c
index acede747..38aa3a7e 100644
--- a/vpn/plugins/vpn.c
+++ b/vpn/plugins/vpn.c
@@ -553,6 +553,13 @@ static int vpn_disconnect(struct vpn_provider *provider)
}
data->state = VPN_STATE_DISCONNECT;
+
+ if (!vpn_driver_data->vpn_driver->disconnect) {
+ DBG("Driver has no disconnect() implementation, set provider"
+ "state to disconnect.");
+ vpn_provider_set_state(provider, VPN_PROVIDER_STATE_DISCONNECT);
+ }
+
connman_task_stop(data->task);
return 0;
--
2.20.1
------------------------------
Message: 6
Date: Tue, 23 Apr 2019 15:53:28 +0300
From: Jussi Laakkonen <[email protected]>
To: [email protected]
Subject: [PATCH 3/3] vpn: Disconnect via provider when transport is
gone or not valid.
Message-ID: <[email protected]>
Use connman_provider_disconnect() to disconnect the provider instead of
calling disconnect_provider() when VPN transport is no longer available.
disconnect_provider() is called by provider.c when disconnecting (via
provider_disconnect() that is registered as disconnect callback
function). Using provider to disconnect VPN the state transition from
ready to idle will be then complete.
Also, no need to check if the service_ident is NULL since service lookup
(connman_service_lookup_from_identifier()) will immediately return NULL.
In such case valid transport check (vpn_is_valid_transport()) returns
false.
---
plugins/vpn.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/plugins/vpn.c b/plugins/vpn.c
index 11bab154..66d7661b 100644
--- a/plugins/vpn.c
+++ b/plugins/vpn.c
@@ -1909,13 +1909,14 @@ static bool vpn_is_valid_transport(struct
connman_service *transport)
static void vpn_disconnect_check_provider(struct connection_data *data)
{
- if (data->service_ident && provider_is_connected(data)) {
+ if (provider_is_connected(data)) {
+ /* With NULL service ident NULL is returned immediately */
struct connman_service *service =
connman_service_lookup_from_identifier
(data->service_ident);
if (!vpn_is_valid_transport(service)) {
- disconnect_provider(data);
+ connman_provider_disconnect(data->provider);
}
}
}
--
2.20.1
------------------------------
Message: 7
Date: Tue, 23 Apr 2019 18:22:42 +0300
From: Jussi Laakkonen <[email protected]>
To: [email protected]
Subject: [PATCH 0/5] Include VPNs in service.c autoconnect process.
Message-ID: <[email protected]>
This set of patches includes VPN connections into service.c autoconnect
procedure. The general autoconnection of VPNs is improved and is
triggered also when the default service changes.
First, run_vpn_auto_connect() is enhanced to re-add itself to mainloop
if there are VPNs with autoconnect set. Delay increases every 30s by 1s
up to 10s if the connection does not succeed, starting with 1s delay
after initial.
Second, the service state is indicated when automatically triggered
connection succeeds in order to get the state processed also by
plugins/vpn.c.
Third, the enhanced run_vpn_auto_connect() is required to be removed
from mainloop if running and there is a change in network conditions.
It is needed because with increasing delays the VPN connection may
have delay set in 10s and with changing network conditions the
connection should happen more quickly.
Fourth, the service connection in service.c is going through new
do_auto_connect() function that calls __connman_service_auto_connect()
for other than VPN services and vpn_auto_connect() for VPNs. Reason is
simply that processes are different. VPN is the only service that
requires another service to run it on.
Fifth, when default service changes and the new default is not VPN it
is set to trigger vpn_auto_connect() to ensure attempt of VPN
autoconnection in case networking conditions change.
Jussi Laakkonen (5):
service: Re-add run_vpn_auto_connect() with increasing delays to main
loop
service: Indicate service state when autoconnect succeeds.
service: Remove existing VPN auto connect from main loop.
service: Implement a do_auto_connect() to include VPNs in autoconnect.
service: Call vpn_auto_connect() when default service changes.
src/service.c | 151 +++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 138 insertions(+), 13 deletions(-)
--
2.20.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 42, Issue 16
***************************************
