Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: Using connman with multiple active interfaces (Patrik Flykt)
2. Re: Using connman with multiple active interfaces (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Wed, 02 Nov 2016 11:28:18 +0200
From: Patrik Flykt <[email protected]>
To: Lukasz Nowak <[email protected]>, [email protected], Daniel
Wagner <[email protected]>
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
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"
> applications.
>
> 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
> enough.
>
> 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
needed.
> There was a discussion here, in March, about something very similar
> to what we are trying to do:
> https://lists.01.org/pipermail/connman/2016-March/000532.html
> https://endocode.com/blog/2016/03/22/multipathtcp-support-for-connman
> /
> https://github.com/endocode/connman
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.
Cheers,
Patrik
------------------------------
Message: 2
Date: Wed, 2 Nov 2016 12:28:59 +0100
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, Lukasz Nowak
<[email protected]>, [email protected]
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
[Sorry for late response. Attending LPC makes it hard to
follow stuff, high altitude and other things :)]
On 11/02/2016 10:28 AM, Patrik Flykt wrote:
> On Tue, 2016-11-01 at 10:41 +0100, Lukasz Nowak wrote:
>> 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.
Yes, sounds very close to the initial use case for the creation of the Session
API.
>> Our primary use case is Mosquitto, an MQTT client. It only currently
>> implements option 2, although option 1 could be ported into it easily
>> enough.
>>
>> 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.
So if you don't use the application matching it should just create
and maintain the policy routing tables for you. In the default
doesn't enable the application matching. That happens if you install
a config file like described in session-policy-format.txt. If that
is not the case it should be fairly simple to fix this. I can't
test it right now, since I just have one link at the moment.
> 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?
It could be that currently the session code will not install the policy
routing table if matching is not configured. As I said it should be
fairly still install the policy routing table even though we don't do
the matching. Then this use case here should work(TM).
> If yes, then the Add AlwaysConnectedTechnologies patch above would be
> needed.
>
>> There was a discussion here, in March, about something very similar
>> to what we are trying to do:
>> https://lists.01.org/pipermail/connman/2016-March/000532.html
>> https://endocode.com/blog/2016/03/22/multipathtcp-support-for-connman
>> /
>> https://github.com/endocode/connman
>
> 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.
Sure, that could also be done but I fear that will be more work than getting
Session API working. Let's try if we have a quick win with the Sessions.
I don't think I can't do anything this week. Needs to wait a bit. If you
want to give it yourself a go see in session.c if we this kind of code
below prevents it:
static int init_routing_table()
{
int err;
if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN)
return 0;
[...]
}
CONNMAN_SESSION_ID_TYPE_UNKNOWN is 'no match'. Maybe it should be renamed
at this time now :)
cheers,
daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 13, Issue 2
**************************************
