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. Re: A couple of question regarding tethering (Patrik Flykt)


Message: 1
Date: Wed, 21 Sep 2016 16:46:54 +0300
From: Patrik Flykt <>
To: Jose Blanquicet <>,
Subject: Re: A couple of question regarding tethering
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"


On Tue, 2016-09-20 at 16:17 +0200, Jose Blanquicet wrote:
> Hi,
> 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()
> function.

As set_tethering() may have more than one driver to try, it will try to
get a decent answer to the caller. It will return 0 if no driver
returned error, -EINPROGRESS if at least one driver is still enabling
tethering or -EOPNOTSUPP if no driver supported tethering. Therefore it
is not useful to report the status of an individual driver.

> 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
> return?

This comes back to the fact that tethering is done per technology,
which means all devices for that technology are supposed to be used for
tethering. This is to cover for the situation that there are e.g. two
ethernet cards on the device, and tethering is enabled for ethernet
technology as a whole. It is not possible to specify a particular card,
as the individual cards are not exposed to the user.

> 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).

Notice that tethering can be enabled for all these technologies, but
enabling the bridge i/f and dhcp server needs to happen only once. Yes,
error values should perhaps be propagated and the error cases were (and
are) not really accounted for in the calling code. So yes, errors
should be communicated, but then again issues have not really been a
problem in real life, at least I can't remember any being reported




Subject: Digest Footer

connman mailing list


End of connman Digest, Vol 11, Issue 23

Reply via email to