Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. [RFC 6/8] vpn: Return transport ident with get_property()
(Jussi Laakkonen)
2. [RFC 7/8] provider: Add function to get transport ident from VPN
(Jussi Laakkonen)
3. [RFC 8/8] service: Sort VPNs using the transport service if connected
(Jussi Laakkonen)
4. RE: [PATCH] service: Allow only user connection after WiFi failure
(VAUTRIN Emmanuel (Canal Plus Prestataire))
----------------------------------------------------------------------
Date: Fri, 26 Mar 2021 17:58:23 +0200
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: [RFC 6/8] vpn: Return transport ident with get_property()
To: connman@lists.01.org
Message-ID: <20210326155825.3938-7-jussi.laakko...@jolla.com>
Return the service_ident with "Transport" keyword given to
get_property(). Plugin tracks the transport and this is can be used
elsewhere as well.
---
plugins/vpn.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/plugins/vpn.c b/plugins/vpn.c
index 3ed9c322..8acc21f6 100644
--- a/plugins/vpn.c
+++ b/plugins/vpn.c
@@ -153,6 +153,8 @@ static const char *get_string(struct connman_provider
*provider,
return data->host_ip[0];
} else if (g_str_equal(key, "VPN.Domain"))
return data->domain;
+ else if (g_str_equal(key, "Transport"))
+ return data->service_ident;
return g_hash_table_lookup(data->setting_strings, key);
}
--
2.20.1
------------------------------
Date: Fri, 26 Mar 2021 17:58:24 +0200
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: [RFC 7/8] provider: Add function to get transport ident from
VPN
To: connman@lists.01.org
Message-ID: <20210326155825.3938-8-jussi.laakko...@jolla.com>
Get the ident of the transport of the VPN. Use get_property() callback
with "Transport" to get the value.
---
src/connman.h | 2 ++
src/provider.c | 12 ++++++++++++
2 files changed, 14 insertions(+)
diff --git a/src/connman.h b/src/connman.h
index 9f859f19..edd440fc 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -670,6 +670,8 @@ void __connman_provider_list(DBusMessageIter *iter, void
*user_data);
bool __connman_provider_is_immutable(struct connman_provider *provider);
int __connman_provider_create_and_connect(DBusMessage *msg);
const char * __connman_provider_get_ident(struct connman_provider *provider);
+const char * __connman_provider_get_transport_ident(
+ struct connman_provider *provider);
int __connman_provider_indicate_state(struct connman_provider *provider,
enum connman_provider_state state);
int __connman_provider_indicate_error(struct connman_provider *provider,
diff --git a/src/provider.c b/src/provider.c
index 250865f0..a3ec895c 100644
--- a/src/provider.c
+++ b/src/provider.c
@@ -560,6 +560,18 @@ const char *__connman_provider_get_ident(struct
connman_provider *provider)
return provider->identifier;
}
+const char * __connman_provider_get_transport_ident(
+ struct connman_provider *provider)
+{
+ if (!provider)
+ return NULL;
+
+ if (provider->driver && provider->driver->get_property)
+ return provider->driver->get_property(provider, "Transport");
+
+ return NULL;
+}
+
int connman_provider_set_string(struct connman_provider *provider,
const char *key, const char *value)
{
--
2.20.1
------------------------------
Date: Fri, 26 Mar 2021 17:58:25 +0200
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: [RFC 8/8] service: Sort VPNs using the transport service if
connected
To: connman@lists.01.org
Message-ID: <20210326155825.3938-9-jussi.laakko...@jolla.com>
Use the transport to verify the order of the connected VPN services. If
there is a transport service in use that ranks lower than an another
service it means that the order must be changed based on comparing the
transport and the service instead of comparing VPN and the service. This
is because the higher ranking service should then become the transport
of the VPN.
This ensures that when the list is sorted the transport check in
plugins/vpn.c will make VPN to switch to the new transport that is
enabled to be the default. Use of the service ident from hash table for
searching is used because the index cannot be retrieved from the list
while sorting the list.
---
src/service.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/src/service.c b/src/service.c
index cc0b20ef..89ad1f54 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5286,6 +5286,40 @@ void connman_service_unref_debug(struct connman_service
*service,
g_hash_table_remove(service_hash, service->identifier);
}
+static gint service_compare(gconstpointer a, gconstpointer b);
+
+static gint service_compare_vpn(struct connman_service *a,
+ struct connman_service *b)
+{
+ struct connman_provider *provider;
+ struct connman_service *service;
+ struct connman_service *transport;
+ const char *ident;
+ bool reverse;
+
+ if (a->provider) {
+ provider = a->provider;
+ service = b;
+ reverse = false;
+ } else if (b->provider) {
+ provider = b->provider;
+ service = a;
+ reverse = true;
+ } else {
+ return 0;
+ }
+
+ ident = __connman_provider_get_transport_ident(provider);
+ transport = connman_service_lookup_from_identifier(ident);
+ if (!transport)
+ return 0;
+
+ if (reverse)
+ return service_compare(service, transport);
+
+ return service_compare(transport, service);
+}
+
static gint service_compare(gconstpointer a, gconstpointer b)
{
struct connman_service *service_a = (void *) a;
@@ -5300,6 +5334,17 @@ static gint service_compare(gconstpointer a,
gconstpointer b)
b_connected = is_connected(state_b);
if (a_connected && b_connected) {
+ int rval;
+
+ /* Compare the VPN transport and the service */
+ if ((service_a->type == CONNMAN_SERVICE_TYPE_VPN ||
+ service_b->type == CONNMAN_SERVICE_TYPE_VPN) &&
+ service_b->type != service_a->type) {
+ rval = service_compare_vpn(service_a, service_b);
+ if (rval)
+ return rval;
+ }
+
if (service_a->order > service_b->order)
return -1;
--
2.20.1
------------------------------
Date: Fri, 26 Mar 2021 16:59:04 +0000
From: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Subject: RE: [PATCH] service: Allow only user connection after WiFi
failure
To: Jussi Laakkonen <jussi.laakko...@jolla.com>,
"connman@lists.01.org" <connman@lists.01.org>
Message-ID: <pr1pr02mb4794fc62d1bf2189347f43a693...@pr1pr02mb4794.eur
prd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Jussi,
> Could this be treated in some other manner as I suspect (I haven't
> tested this at all yet) that in mobile environment when AP is shut down,
> lost or it simply crashes and does not get up instantly (put down for
> maintenance) the service may end up in failure state? In that case user
> interaction would not be required for re-connecting and autoconnect
> should handle that case. But I understand your point here that
> repeatedly re-connecting has its downsides as well.
Please let me give you a bit of context.
This patches follows Daniel answer to the
"[PATCH] service: Fix autoconnect after rejection" topic (2021/01/25), where
I proposed to recover the auto-connection on a service in failure state.
Without this refused patch, which means the current sources, I really doubt
that your service will exit failure state without an end-user interaction.
But it only concerns the service, not the complete auto-connection
mechanism, which shall continue. And if the AP is shut down, it will probably
disappear after a scan, and appear again, as a new one, when AP will be
available again.
> We have our own implementation of the WiFi plugin and I haven't tried
> with the plugin upstream has so this is just a guess/concern from my part.
It is important to share you concern, but I think you should face the
same behavior, with or without it. The easiest way is to test it.
Best Regards
Emmanuel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
End of connman Digest, Vol 65, Issue 9
**************************************
