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. [PATCH v5 8/8] doc: Session multi-interface routing (Lukasz Nowak)
2. PacRunner DBus activation (David Woodhouse)
3. Re: PacRunner DBus activation (Marcel Holtmann)
4. Re: PacRunner DBus activation (Atul Anand)
5. Re: [PATCH] session: Maintain bearer priority in policy file
and check for other services when service lost (Daryl Nebrich)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Feb 2017 10:43:34 +0000
From: Lukasz Nowak <[email protected]>
To: [email protected]
Subject: [PATCH v5 8/8] doc: Session multi-interface routing
Message-ID: <[email protected]>
From: Lukasz Nowak <[email protected]>
Update session overview and API documents to demonstrate how sessions
can be used to maintain multiple connections in parallel.
---
doc/session-api.txt | 23 +++++++++++++++++++++++
doc/session-overview.txt | 31 +++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/doc/session-api.txt b/doc/session-api.txt
index 3aac535..e8da522 100644
--- a/doc/session-api.txt
+++ b/doc/session-api.txt
@@ -182,3 +182,26 @@ Settings string State [readonly]
(This setting will be removed when the unique process
identification problem is solved.)
+ string AllowedInterface [readwrite] [experimental]
+
+ This field is used to bind a session to a specific
+ network interface. If this field is empty, the first
+ interface from a list of available ones will be used.
+ Also "*" string matches any interface.
+
+ Only one interface may be specified.
+
+ If a specified network interface is not available
+ (e.g. because AllowedBearers filters it out), the
+ session will not go online.
+
+ boolean SourceIPRule [readwrite] [experimental]
+
+ If set to true the session will create source IP
+ address rule in the firewall, which redirects traffic
+ to that session's routing table.
+
+ Each session maintains a dedicated routing table, with
+ a default route. When the source IP rule is enabled,
+ an application can select which session/interface to
+ send traffic on, using bind-before-connect mechanism.
diff --git a/doc/session-overview.txt b/doc/session-overview.txt
index 2393167..976c351 100644
--- a/doc/session-overview.txt
+++ b/doc/session-overview.txt
@@ -92,3 +92,34 @@ The default session configuration does not enable the per
application
routing. Sessions are still useful in this setup, because the
notification of sessions is still available, e.g. the online/offline
notification.
+
+
+Multiple per-session routing tables
+===================================
+
+Sessions can be used in an environment with multiple network interfaces,
+where an application needs to direct outside traffic through a selected
+interface(s). ConnMan can maintain multiple sessions in a connected
+stated, and the application can dynamically, on a per-socket basis,
+select which session is used to route traffic.
+
+Example use cases are:
+- monitoring liveness of multiple connected interfaces, by sending
+ end-to-end heartbeat traffic on all of them in parallel.
+- prioritising traffic - e.g. sensitive data can be transferred over a slow,
+ but secure connection, while big, public downloads use a second session
+
+By default, ConnMan maintains only one online service. So it is impossible
+to send external traffic (routed through a gateway) on multiple interfaces.
+In order to enable this functionality, an application needs to issue the
+following API calls:
+- create multiple sessions, one for each interface to be used
+- set each session's AllowedInterface config field to the required interface
+ name (eth0, eth1, wlan0, ppp0, etc.)
+- set each session's SourceIPRule config field to true
+- connect each session (or the service it is using)
+
+That will instruct ConnMan to create multiple routing tables, with default
+routes in them. After that, the application can issue a bind() call on each
+socket, using required interface's source IP address. The bind() call must
+be made before a connect() call on a socket.
--
2.7.4
------------------------------
Message: 2
Date: Fri, 03 Feb 2017 11:25:46 +0000
From: David Woodhouse <[email protected]>
To: connman <[email protected]>
Cc: Sriram Ramkrishna <[email protected]>, Colin Walters
<[email protected]>, atuljhp <[email protected]>
Subject: PacRunner DBus activation
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
PacRunner is currently started by DBus activation by either clients
(the org.pacrunner.Client interface) or managers (the
org.pacrunner.Manager interface).
ConnMan watches the bus, and when PacRunner is activated, will push the
proxy configuration into place. I don't think NetworkManager does this
(yet?). And certainly in the case where neither ConnMan nor a suitable
version of NetworkManager are being used, nothing will.
I'm not quite sure why we use this model ? why doesn't ConnMan send the
configuration to PacRunner unconditionally? If it's present in the
system, it'll be activated and start working. If not, it won't.
The only disadvantage of such an approach would be if PacRunner is
configured for DBus activation but no clients are ever going to use
it... and I don't think that's a problem. A poorly configured system
might dedicate resources to running things it doesn't need to run...
film at 11.
It might be better to have a model where PacRunner is automatically
activated for *manager* connections, but never for client connections.
That way, a client can *try* talking to PacRunner, and know that it
isn't configured in the system when it doesn't get a reply.
As things stand, we have the problem discussed in
https://github.com/libproxy/libproxy/pull/35?where we can't know if
it's sensible to talk to PacRunner or not. We really *want* libproxy to
defer to PacRunner as its highest-priority option, but *only* if
PacRunner is actually configured.
At this point I suspect it isn't feasible to really change the
activation model. Perhaps we can add a 'bool IsConfigured()' method to
the client API though.
That function will return false if proxy_config_timeout() happened, or
true if any configuration has ever been received. (And will wait while
proxy_updating==-1, of course).
Does that seem reasonable? Any better ideas?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20170203/5d1cba57/attachment-0001.bin>
------------------------------
Message: 3
Date: Fri, 3 Feb 2017 12:46:48 +0100
From: Marcel Holtmann <[email protected]>
To: David Woodhouse <[email protected]>
Cc: connman <[email protected]>, Colin Walters
<[email protected]>, atuljhp <[email protected]>, Sriram Ramkrishna
<[email protected]>
Subject: Re: PacRunner DBus activation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi David,
> PacRunner is currently started by DBus activation by either clients
> (the org.pacrunner.Client interface) or managers (the
> org.pacrunner.Manager interface).
>
> ConnMan watches the bus, and when PacRunner is activated, will push the
> proxy configuration into place. I don't think NetworkManager does this
> (yet?). And certainly in the case where neither ConnMan nor a suitable
> version of NetworkManager are being used, nothing will.
>
> I'm not quite sure why we use this model ? why doesn't ConnMan send the
> configuration to PacRunner unconditionally? If it's present in the
> system, it'll be activated and start working. If not, it won't.
>
> The only disadvantage of such an approach would be if PacRunner is
> configured for DBus activation but no clients are ever going to use
> it... and I don't think that's a problem. A poorly configured system
> might dedicate resources to running things it doesn't need to run...
> film at 11.
>
> It might be better to have a model where PacRunner is automatically
> activated for *manager* connections, but never for client connections.
>
> That way, a client can *try* talking to PacRunner, and know that it
> isn't configured in the system when it doesn't get a reply.
>
> As things stand, we have the problem discussed in
> https://github.com/libproxy/libproxy/pull/35 where we can't know if
> it's sensible to talk to PacRunner or not. We really *want* libproxy to
> defer to PacRunner as its highest-priority option, but *only* if
> PacRunner is actually configured.
>
> At this point I suspect it isn't feasible to really change the
> activation model. Perhaps we can add a 'bool IsConfigured()' method to
> the client API though.
>
> That function will return false if proxy_config_timeout() happened, or
> true if any configuration has ever been received. (And will wait while
> proxy_updating==-1, of course).
>
> Does that seem reasonable? Any better ideas?
we can certainly change this. There is certainly no harm in just starting
PACrunner and keeping it running. But what is the deal with libproxy? When I
wrote the PACrunner version of libproxy which is fully API compatible and an
instant drop in recplacement. So if applications just ask libproxy, the
PACrunner will be started. That simple.
Regards
Marcel
------------------------------
Message: 4
Date: Fri, 3 Feb 2017 18:09:35 +0530
From: Atul Anand <[email protected]>
To: David Woodhouse <[email protected]>
Cc: connman <[email protected]>, Colin Walters
<[email protected]>, atuljhp <[email protected]>, Sriram Ramkrishna
<[email protected]>
Subject: Re: PacRunner DBus activation
Message-ID:
<CABYWKtnXUtzeJM9BJh+YZF_uM24f99=tg_bclonule3ktna...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hey,
Just for confirmation:
On 2/3/17, David Woodhouse <[email protected]> wrote:
> PacRunner is currently started by DBus activation by either clients
> (the org.pacrunner.Client interface) or managers (the
> org.pacrunner.Manager interface).
>
> ConnMan watches the bus, and when PacRunner is activated, will push the
> proxy configuration into place. I don't think NetworkManager does this
NM adopts the same model[1]. It keeps an eye on PacRunner and push
configs as soon as it appears on Bus.
> (yet?). And certainly in the case where neither ConnMan nor a suitable
> version of NetworkManager are being used, nothing will.
>
Right, proxy feature in NM is available since 1.6 [2].
> I'm not quite sure why we use this model ? why doesn't ConnMan send the
> configuration to PacRunner unconditionally? If it's present in the
> system, it'll be activated and start working. If not, it won't.
>
We just query with NO_FLAGS, maybe we should be doing something more.
> The only disadvantage of such an approach would be if PacRunner is
> configured for DBus activation but no clients are ever going to use
> it... and I don't think that's a problem. A poorly configured system
> might dedicate resources to running things it doesn't need to run...
> film at 11.
>
> It might be better to have a model where PacRunner is automatically
> activated for *manager* connections, but never for client connections.
>
> That way, a client can *try* talking to PacRunner, and know that it
> isn't configured in the system when it doesn't get a reply.
>
> As things stand, we have the problem discussed in
> https://github.com/libproxy/libproxy/pull/35 where we can't know if
> it's sensible to talk to PacRunner or not. We really *want* libproxy to
> defer to PacRunner as its highest-priority option, but *only* if
> PacRunner is actually configured.
>
> At this point I suspect it isn't feasible to really change the
> activation model. Perhaps we can add a 'bool IsConfigured()' method to
> the client API though.
>
> That function will return false if proxy_config_timeout() happened, or
> true if any configuration has ever been received. (And will wait while
> proxy_updating==-1, of course).
>
> Does that seem reasonable? Any better ideas?
[1]
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-pacrunner-manager.c#n249
[2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS
Thanks,
Atul Anand
------------------------------
Message: 5
Date: Fri, 3 Feb 2017 09:22:23 -0500
From: Daryl Nebrich <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] session: Maintain bearer priority in policy file
and check for other services when service lost
Message-ID:
<CANmGHYtyLS4X8tGLwV3qRDnX0aGZY-J_qn6ZLA72=g98ko9...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Ok, thanks for your patience. First time doing this. Will resubmit shortly.
Btw, I didn't get any list emails during the day ET yesterday. They
all came in overnight. Someone else mentioned seeing delays also.
On Fri, Feb 3, 2017 at 1:50 AM, Daniel Wagner <[email protected]> wrote:
> Hi Daryl,
>
> On 02/02/2017 04:05 PM, Daryl Nebrich wrote:
>>
>> The session_policy_local files can have multiple services listed in
>> AllowedBearers.
>> The order was not being maintained by apply_policy_on_bearers(). Reversed
>> loop
>> order so that the priority order in policy file is maintained.
>>
>> session_match_service() now checks the priority of a new service before
>> switching.
>>
>> When a session service is lost, handle_service_state_offline() removes the
>> old service
>> but does not check for other available services. Added call to
>> session_activate().
>
>
> Looks pretty good. Though I would prefer to have two patches one which does
> the logic fix in the filtering and the second which introduces the
> additional check. Actually make it three patches, because the last one
> 'added call to session_activate()' deserves an description in the commit
> message why you do it and we don't need to comment then.
>
>> ---
>> src/session.c | 32 ++++++++++++++++++++++----------
>> 1 file changed, 22 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/session.c b/src/session.c
>> index 267477b..d40db0f 100644
>> --- a/src/session.c
>> +++ b/src/session.c
>> @@ -686,18 +686,18 @@ static int parse_bearers(DBusMessageIter *iter,
>> GSList **list)
>> return 0;
>> }
>>
>> -static void filter_bearer(GSList *policy_bearers,
>> - enum connman_service_type bearer,
>> +static void filter_bearer(GSList *bearers,
>> + enum connman_service_type policy,
>> GSList **list)
>> {
>> - enum connman_service_type policy;
>> + enum connman_service_type bearer;
>> GSList *it;
>>
>> - if (!policy_bearers)
>> + if (!bearers)
>> return;
>>
>> - for (it = policy_bearers; it; it = it->next) {
>> - policy = GPOINTER_TO_INT(it->data);
>> + for (it = bearers; it; it = it->next) {
>> + bearer = GPOINTER_TO_INT(it->data);
>>
>> if (policy != bearer)
>> continue;
>> @@ -710,15 +710,15 @@ static void filter_bearer(GSList *policy_bearers,
>> static void apply_policy_on_bearers(GSList *policy_bearers, GSList
>> *bearers,
>> GSList **list)
>> {
>> - enum connman_service_type bearer;
>> + enum connman_service_type policy_bearer;
>> GSList *it;
>>
>> *list = NULL;
>>
>> - for (it = bearers; it; it = it->next) {
>> - bearer = GPOINTER_TO_INT(it->data);
>> + for (it = policy_bearers; it; it = it->next) {
>> + policy_bearer = GPOINTER_TO_INT(it->data);
>>
>> - filter_bearer(policy_bearers, bearer, list);
>> + filter_bearer(bearers, policy_bearer, list);
>> }
>> }
>
>
> So this above is the first patch.
>
>
>> @@ -1549,15 +1549,24 @@ static bool session_match_service(struct
>> connman_session *session,
>> {
>> enum connman_service_type bearer_type;
>> enum connman_service_type service_type;
>> + enum connman_service_type current_service_type;
>> GSList *list;
>>
>> if (policy && policy->allowed)
>> return policy->allowed(session, service);
>>
>> + /* Handle multiple bearers and priorities in session policy. */
>> + current_service_type = connman_service_get_type(session->service);
>> +
>> for (list = session->info->config.allowed_bearers; list; list =
>> list->next) {
>> bearer_type = GPOINTER_TO_INT(list->data);
>> service_type = connman_service_get_type(service);
>>
>> + /* Keep using current service if higher priority. */
>> + if (bearer_type == current_service_type) {
>> + return false;
>> + }
>> +
>
>
> Second one.
>
> And for one liners you can leave the brackets away, so just do
>
> if (bearer_type == current_service_type)
> return false;
>
>> if (bearer_type == service_type)
>> return true;
>> }
>> @@ -1689,6 +1698,9 @@ static void handle_service_state_offline(struct
>> connman_service *service,
>>
>> session->service = NULL;
>> update_session_state(session);
>> +
>> + /* Check if another allowed bearer is available. */
>> + session_activate(session);
>> }
>> }
>
>
> Third patch. If we have a nice commit message we don't need the comment
> here.
>
> Thanks,
> Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 6
**************************************
