Thanks for your answers.
So now it's clear that my use case is not supported.
If I want to handle that either I manage this outside Connman via a
small daemon checking this and sending command to connman via DBus for
instance (I made the assumption that we can send this kind of
information about connectivity via DBus), or change the code of Connman
for continuous connectivity check.
Do you see any other option, and do you have any recommendation on one
or the other ?
On 29/04/2016 08:50, Patrik Flykt wrote:
On Thu, 2016-04-28 at 08:55 +0200, Florent Le Saout wrote:
> I'm looking for a network manager.
> I would like to use ConnMan in an embedded system. It seems that it
> provides most of the features I'm looking for, including 3G and VPN
> But after some research it seems that there is maybe one missing
> point in it. Let say I have the following setup :
> Ethernet connection as preferred connection
> 3/4G connection as backup/failover connection
> My Ethernet is always on and dhcp server is properly providing IP,
> cable is still plugged in, and power on the line is still there, but
> sometimes the internet connectivity is lost. So in that case it ll
> switch to the 3G/4G connection. But then as soon as possible, when
> connectivity is back online via the ethernet, I want to switch back
> to it for performance and cost reason.
> Is this supported by default, or is there a way to configure it that
> way ?
> I found this post(http://comments.gmane.org/gmane.linux.network.connm
> an/10238) which seems to say that it was not supported at that time,
> since there is no periodic check (February 2013).
> And also from the documentation :
> Favorite (saved) networks that have autoconnect enabled are
> considered when autoconnecting services. These services are marked
> with '*' and 'A' in connmanctl, respectively. By default ConnMan
> autoconnects these in the order they are shown in the list of
> services until one of them gets connected. After that the
> autoconnected service is in use and ConnMan won't select a new one
> until the network goes out of range. When the service goes out of
> range or gets disconnected from the network infrastructure side,
> autoconnect is re-run and another favorite autoconnectable service is
> So I want to make sure I got the correct understanding on that ?
> Feel free to ask for more informations if this is unclear.
Autoconnect works for the immediately connected networks links, i.e.
when a wifi scan is done and a known network is found and also when an
ethernet network cable is connected. So this part works as documented
and the service is being used as long as the network link is kept
Now the issue you have is that the connection to "Internet" broke
somewhere after the first network link. For this there is no good
solution, ConnMan does it's connectivity discovery once after a network
is connected. ConnMan makes a decent guess that the network will work
in the intended way also later. ConnMan does not make any connectivity
assumptions other than informing the user about its connected state; no
changes are made to the inner workings of ConnMan depending on the
network 'ready' or 'online' states.
So the question that doesn't have a good answer is with what frequency
should temporary glitches be detectable in the first place? And to what
part of the "Internet", as the connectivity check may succeed but the
end point that the application cares about won't be reachable. And as
nothing is changed internally, 'ready' and 'online' state correspond to
the same networking functionality should the connection to the
"Internet" disappear/reappear beyond the first connected network link.
*Florent LE SAOUT*
Embedded Software Developer
AUSY contractor for KERLINK