[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
> 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.
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
> There was a discussion here, in March, about something very similar
> to what we are trying to do:
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()
if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN)
CONNMAN_SESSION_ID_TYPE_UNKNOWN is 'no match'. Maybe it should be renamed
at this time now :)