On Tue, 2016-11-01 at 10:41 +0100, Lukasz Nowak wrote:
We are building a system which has 4 network interfaces: ethernet
(private), ethernet (public), wifi, cellular.
We need to keep multiple of them (ideally all, if available) on-line,
and allow the applications to select which one they want to use on a
per-socket basis. This includes access to internet, so we would need
a default route established on every interface.
Also, there will be a management application, which will select the
preferred interface, which should be used by all other "normal"
As far as I can see, there are two potential options to do that:
1. Add multiple default routes to the main routing table, with
different metrics. In that case to select an interface an application
should call setsockopt(SO_BINDTODEVICE). Example: ping -I eth1
There was a patch about AlwaysConnectedTechnologies to cover for more
than one interface being connected, see https://lists.01.org/pipermail
/connman/2016-September/020901.html and the comments a month later.
This would enable all interface to be connected at the same time. This
with only one default route, though, so multiple default routes would
need some additional work.
2. Create multiple routing tables with iproute2, and rules filtering
based on source address. Application uses bind(adapter ip address)
before connect(). Example: ping -I 10.20.30.40
This looks like a problem the Session API and code was meant to solve.
Our primary use case is Mosquitto, an MQTT client. It only currently
implements option 2, although option 1 could be ported into it easily
As far as I can see, currently, neither option is implemented in
Connman. There is only one on-line interface at a time.
The session API, and per-application routing, seems to be the closest
thing, but it still does not allow the application to freely chose
which interface it wants to use.
The interfaces the applications end up being routed out on depend on
the ones allowed by the session policy. There can be more than one
interface to choose from, but was it so that the current code was happy
if one of the specified interfaces was connected per session? Wagi can
enlighten us on this, I suppose?
If yes, then the Add AlwaysConnectedTechnologies patch above would be
By reading those mails/pages this looks similar to the above
enhancements. As I have not seen any patches submitted to ConnMan ml,
it's hard to say what the end result would be.
My opinion would be to finish AlwaysConnectedTechnologies and to look
at the multiple default route feature after that. Using Session API it
is then possible to restrict application routing further based on what
the applications need to be doing.