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 (Lukasz Nowak)
2. Re: Using connman with multiple active interfaces (Dragos Tatulea)
----------------------------------------------------------------------
Message: 1
Date: Thu, 3 Nov 2016 14:00:56 +0000
From: Lukasz Nowak <[email protected]>
To: Daniel Wagner <[email protected]>, Patrik Flykt
<[email protected]>, [email protected]
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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.
Thanks.
Regards,
Lukasz Nowak
On 02/11/16 11:28, Daniel Wagner wrote:
> 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
>
------------------------------
Message: 2
Date: Thu, 3 Nov 2016 18:06:23 +0100
From: Dragos Tatulea <[email protected]>
To: Lukasz Nowak <[email protected]>
Cc: Daniel Wagner <[email protected]>, Patrik Flykt
<[email protected]>, [email protected], Dragos Tatulea
<[email protected]>
Subject: Re: Using connman with multiple active interfaces
Message-ID:
<CAMPxJtU6=fhRJZfYkwkU2Ur=pylntku9wu5o_z78y6hc81r...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
Better late than never.
>>>> 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.
>>>
I haven't spent any time into cleaning these up because I was under
the impresion that they weren't interesting enough for upstreaming.
Although the patchest is quite large, some things are not required and
the service part is the easiest.
I could clean them up and send them over if you would be interested in
reviewing and testing them.
Thanks,
Dragos
On Thu, Nov 3, 2016 at 3:00 PM, Lukasz Nowak <[email protected]> wrote:
> 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.
> Thanks.
>
> Regards,
> Lukasz Nowak
>
>
>
> On 02/11/16 11:28, Daniel Wagner wrote:
>> 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
>>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 13, Issue 3
**************************************
