So I had a good look at the sessions. If I understand correctly,
each session sets an iproute2 rule to forward packets
with a session-specific fwmark to the correct routing table.
The marks are added with iptables based on UID, GID or SELINUX.
This is quite a bit off from what we need: having one application
freely choosing which interface to send traffic through.
Firstly, can a single application connect multiple sessions?
(one for each interface)
Even if yes, all the sessions would then receive the same policy,
so only one iptables marking entry would be active, i.e. only
one routing table would be used. The application would not have
a way to change that.
Also, if I understand correctly, if an application opens a session
with a UID/GID policy, the iptables/iproute rules will immediately
affect all processes with the same UID/GID - is that correct?
Ideally, what we need would is either:
- set an iproute2 rule to use correct routing table based on packet source ip
- use iptables to mark packets based on source ip
In either case, I cannot see how it can be easily added to the
policy model. Unless the application could choose a specific policy when
creating a session.
For the AlwaysConnectedTechnologies: this change does not do
a lot. We can achieve the same effect by the application manually
connecting all services. In either case, the routing table will
only be established for one service. So the services in Ready
state will not be usable for sending external traffic.
Automatically adding additional routing tables for each AlwaysConnectedTechnology,
and iproute2 rules based on source ip, would do the job. But it
would have to be independent of the Sessions.
Let me know if you have any further thoughts about this functionality.
On 02/11/16 11:28, Daniel Wagner wrote:
[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
>> 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
>> 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 :)