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] service: Replace g_timeout_add_seconds() with
g_idle_add() (Saurav Babu)
2. [RFC] Proposal for ConnMan session API extensions
(Nakamura, Yusuke (ADITJ/SWG))
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Jan 2017 14:15:52 +0530
From: Saurav Babu <[email protected]>
To: [email protected]
Cc: [email protected], Saurav Babu <[email protected]>
Subject: [PATCH] service: Replace g_timeout_add_seconds() with
g_idle_add()
Message-ID: <[email protected]>
Passing 0 as timeout to g_timeout_add_seconds() is equivalent to g_idle_add()
According to glib documentation "the first call of the timer may
not be precise for timeouts of one second."
---
src/service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/service.c b/src/service.c
index 8480350..043a7a0 100644
--- a/src/service.c
+++ b/src/service.c
@@ -4001,7 +4001,7 @@ void __connman_service_auto_connect(enum
connman_service_connect_reason reason)
if (!__connman_session_policy_autoconnect(reason))
return;
- autoconnect_timeout = g_timeout_add_seconds(0, run_auto_connect,
+ autoconnect_timeout = g_idle_add(run_auto_connect,
GUINT_TO_POINTER(reason));
}
--
1.9.1
------------------------------
Message: 2
Date: Mon, 16 Jan 2017 13:00:33 +0000
From: "Nakamura, Yusuke (ADITJ/SWG)" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"EXTERNAL Thorwirth Bjoern (Brunel, CM-CI1/ERN5-E)"
<[email protected]>, "Hoyer, Marko (ADITG/SW2)"
<[email protected]>, "Ishikawa, Tetsuri (ADITJ/SWG)"
<[email protected]>
Subject: [RFC] Proposal for ConnMan session API extensions
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello everybody
We would like to propose two extensions to the session API interface of
ConnMan. The first extension enables a service differentiation for processes
run by the same user. It allows ConnMan to differentiate between bearer usage
permissions and the respective priorities based on the requested service type.
The second extension enables session-based routing based on source IPs. This
mechanism is meant as an alternative means for differentiating between traffic
of session API users. Source IP based routing may be used to route traffic from
non-local sources, e.g. remote hosts or virtual machines/containers.
1 User service differentiating session API
1.1 State of art
A minimal policy configuration in the session API takes the form
[<policy_name>]
uid=<system user ID>
AllowedBearers=[<bearer>]+,
where a calling process that implements the session API is identified by the
user ID it is run as. All processes of the same user share the same list of
allowed bearers, and the same priority for choosing between available bearers
is applied.
1.2 Advantages of proposed extension
Our extension allows processes to select a service context for which the
routing decision is made. Several use cases are enabled through the extension:
(1) An application that implements an interactive webservice, e.g. a Facebook
agent, can be configured to use different bearers than a background process
running a regular system update mechanism as the same user.
(2) An application that runs different encapsulated services, e.g. a webbrowser
executing a Facebook webservice, a device manufacturer's portal site, and an
automatic update mechanism, may be configured to use different bearers based on
the currently active service.
1.3 Implementation details
The configuration for the extension is lightweight
[<policy_name>]
uid=<system user ID>
service=<service ID>
AllowedBearers=[<bearer>]+,
where the new parameter service defaults to * (any) if unset. If no default
rule exists and the intended service is unknown or not set by the calling
process, the session API denies routing.
In order to indicate the intended service, the calling process leverages the
option to set parameters during the CreateSession(dict settings, object
notifier) method call in the ConnMan Manager API on session establishment, see
Figure 1. We propose to introduce a new parameter service for this purpose.
[cid:[email protected]]
Optionally, this parameter may be changed by a Update(dict settings) request
during the session lifetime.
2 Source IP based routing
2.1 State of art
The session API makes the decision which bearer shall be used by a requesting
user. It then initiates the following steps
1. It generates a rule that unambiguously attaches a mark <MARK> to every
packet originating from the user <UID> (resp. a GID) that passes through the
kernel.
iptables -t mangle -A OUTPUT -m owner --uid-owner <UID> -j MARK --set-mark
<MARK>
2. It generates a new routing table by the name of <MARK> which is applied for
all packets matching the mark value <MARK>
ip rule add fwmark <MARK> table <MARK>
3. It adds a default route to the newly created routing table matching the
intended bearer <BEARER>.
ip route add default via XXX dev <BEARER> table <MARK>
UID/GID based differentiation is only applicable for traffic generated at the
local system.
2.2 Advantages of proposed extension
Our extension allows the session API based to route alternatively based on the
source IP of a packet. Several use cases are enabled through the extension:
(1) The host implementing the ConnMan session API may act as a service aware
router to an entire network. For example, different hosts in the network may
use different outgoing network connections.
(2) If the host implements virtual machines/containers that are connected
through a Linux bridge, the session API can route their traffic according to
the intended policies.
In order to enable these scenarios, hosts/virtual machines/containers require
authenticated access to the system DBus. Alternatively, using the user service
differentiation proposed above, an application running on the host (e.g. a
webportal), may enable routing on behalf of the remote machine.
2.3 Implementation details
The configuration for the extension is lightweight
[<policy_name>]
uid=<system user ID>
SourceIP=[<IP>]+
AllowedBearers=[<bearer>]+,
where the new parameter SourceIP carries one or more IP addresses. If the
parameter is omitted, UID/GID-based routing is applied (backward compatible).
If a single IP is given, routing for all bearers uses this IP address for
differentiation, otherwise the number of IPs must match the number of bearers.
If the nth bearer from the list of allowed bearers is selected, the nth IP is
used.
In the first step of the route establishment, the iptables rule is changed to
iptables -A PREROUTING -t mangle -j MARK --set-mark <MARK>
if source IP based routing is to be used. Note that the rule is added to a
different chain than the original user-based routing.
What do you think about our proposal?
Best regards,
Yusuke Nakamura
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170116/75962fa9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 36528 bytes
Desc: image001.png
URL:
<http://lists.01.org/pipermail/connman/attachments/20170116/75962fa9/attachment.png>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 16
***************************************
