Send connman mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

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

Today's Topics:

   1. A couple of question regarding tethering (Jose Blanquicet)
   2. [PATCH] service: Use PreferredTechnologies for service
      ordering (Maxime Chevallier)


Message: 1
Date: Tue, 20 Sep 2016 16:17:33 +0200
From: Jose Blanquicet <>
Subject: A couple of question regarding tethering
Content-Type: text/plain; charset=UTF-8


I have three quick questions for tethering:

1. If I am not wrong, the return value when setting up an AP in
technology.c:set_tethering() can only be either 0, -EINPROGRESS or
-EOPNOTSUPP. Why it was implemented in such a way? This implementation
prevents to forward any occurred error in driver->set_tethering()

2. There is a specific reason to continue trying to call
set_tethering() on others drivers after one of them has already
replied 0 or -EINPROGRESS? Why do not simply break the loop and

3. Are we sure tethering.c:__connman_tethering_set_enabled() will
always complete successfully? I would prefer to add a return value to
this function and also to connman_technology_tethering_notify() in
order to check that all the operations done inside
__connman_tethering_set_enabled (Create the bridge and start/configure
DHCP server) have finished successfully before indicating tethering
was enabled and recreating the interface (Bridged with "tether") in
wifi.c:sta_remove_callback(). In fact, I would suggest to try to call
connman_technology_tethering_notify() before removing the wifi
interface. Does it make sense for you?
As you could see I mostly referred to wifi technology (plugin),
however this new return value could also be used by other technologies
supporting tethering (bluetooth, gadget, ethernet).


Jose Blanquicet


Message: 2
Date: Tue, 20 Sep 2016 16:42:00 +0200
From: Maxime Chevallier <>
Subject: [PATCH] service: Use PreferredTechnologies for service

When services have the same state, the PreferredTechnologies list needs
to be taken into account for service ordering. This applies when all
services are 'ready' but none is 'online'.

This patch checks for services in PreferredTechnologies before
defaulting to the hardcoded list in service_compare.
 src/service.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/src/service.c b/src/service.c
index 37af5fc..ee10e6c 100644
--- a/src/service.c
+++ b/src/service.c
@@ -4759,6 +4759,20 @@ static gint service_compare(gconstpointer a, 
gconstpointer b)
                return 1;
        if (service_a->type != service_b->type) {
+               unsigned int *tech_array;
+               int i;
+               tech_array = connman_setting_get_uint_list(
+                                               "PreferredTechnologies");
+               if (tech_array) {
+                       for (i = 0; tech_array[i]; i++) {
+                               if (tech_array[i] == service_a->type)
+                                       return -1;
+                               if (tech_array[i] == service_b->type)
+                                       return 1;
+                       }
+               }
                if (service_a->type == CONNMAN_SERVICE_TYPE_ETHERNET)
                        return -1;


Subject: Digest Footer

connman mailing list


End of connman Digest, Vol 11, Issue 22

Reply via email to