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: [PATCH v2 0/7] session: add per-interface routing
(Lukasz Nowak)
2. Re: [RFC] Proposal for ConnMan session API extensions
(Lukasz Nowak)
3. HTTP GET usage for Ready to Online state transition (Lukasz Nowak)
4. Re: Session policy with multiple AllowedBearers (Daryl Nebrich)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Jan 2017 12:37:21 +0000
From: Lukasz Nowak <[email protected]>
To: Daniel Wagner <[email protected]>, 'Marcel Holtmann'
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH v2 0/7] session: add per-interface routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Daniel,
I will change the capitals.
I am hoping to have nftables implementation finished in the next few days. I
will provide a v3 with all the small changes then.
Lukasz
On 22/01/17 18:04, Daniel Wagner wrote:
> Hi Lukasz,
>
> On 01/17/2017 10:17 AM, [email protected] wrote:
>> From: Lukasz Nowak <[email protected]>
>>
>> changes from v1:
>> - added documentation
>> - split firewall and session changes into separate commits
>> - cosmetic updates after v1 review
>
> Overall it looks pretty good to me.
>
> Two small nitpicks: For the commit message title start with a capital:
>
> session: Add ...
>
> And in the doc section use ConnMan instead Connman please.
>
> @Marcel: Are you fine with the proposed Session API extension?
>
> Thanks,
> Daniel
------------------------------
Message: 2
Date: Mon, 23 Jan 2017 13:05:51 +0000
From: Lukasz Nowak <[email protected]>
To: Daniel Wagner <[email protected]>, "Nakamura, Yusuke (ADITJ/SWG)"
<[email protected]>
Cc: "[email protected]" <[email protected]>, "Hoyer, Marko
(ADITG/SW2)" <[email protected]>, "[email protected]"
<[email protected]>, "EXTERNAL Thorwirth Bjoern (Brunel,
CM-CI1/ERN5-E)" <[email protected]>, "Ishikawa,
Tetsuri (ADITJ/SWG)" <[email protected]>
Subject: Re: [RFC] Proposal for ConnMan session API extensions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 22/01/17 19:47, Daniel Wagner wrote:
> Hi Yusuke,
>
> On 01/16/2017 02:00 PM, Nakamura, Yusuke (ADITJ/SWG) wrote:
>> Hello everybody
>
> First, thanks a lot for the detailed proposal. This is really helping
> understanding what you are trying to achieve.
>
>> 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.
>
> That should also be possible with the current code. You might need to write
> your own session plugin for this though. It is quite hard to support all
> types of application/user identification out of the box because it depends
> heavily on the system integrator's choices.
>
> Let me explain this in the section below.
>
>> 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.
>
> If I read this correctly than this could be part of Lukasz Nowak
> patches:
>
> [PATCH v2 0/7] session: add per-interface routing
>
> At least it sets the foundation for it. Again, I'll comment in the section
> below.
>
>> 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.
>
> The session_policy_local.c plugin implements three types of identification.
>
> uid
> gid
> lsm
>
> The last one is of interest. It allows to identify your application using the
> Linux Security Module. If you system used for example SELinux you can
> identify your application using the SELinux label. Unfortunately, as soon you
> use something else, let's say AppAmor or any other LSM, you need to patch
> D-Bus for this.
>
>> 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.
>
> Okay, those are the exact use cases for which the Session API was initially
> added to ConnMan.
>
>
>> 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.
>
> When we were discussing the initial API design, the exact same proposal for
> application identification was on the table. Marcel convinced me that this is
> a rather bad idea. Mainly because you need to trust the application to
> provide the correct ID. There is nothing which stops any random application
> to set the magic ID to get full connectivity.
>
> So the trick is to rely on a trustworthy 3rd party, in our case LSM. What
> type of LSM are you going to use?
>
>> 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.
>
> That is basically lifting the limitation of application only being handled by
> ConnMan. Sounds good to me :)
>
>> 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.
>
> I do not really follow the argumentation on the numbers of IP addresses and
> bearers. Are you trying to match several 'virtual machines' with one session?
> A Session is thought to be only used by one entity, until now that would a
> single application.
>
>> 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?
>
> Thanks again for providing this detailed description. I really appreciate it.
>
> For 1) we should have most of it in place, except bugs obviously.
> Proposal 2) could be part of Lukasz' effort.
>
> @Lukasz do you think proposal 2) could also be addressed by your patches? It
> sounds like a generalization of your patch set.
What my changes do is take interface's IP as the source ip address for the
firewall rule.
If I understand correctly, the proposed change allows an application to provide
an arbitrary IP address for the source ip rule. That ip address can even be
completely external to the machine that ConnMan is running on.
The firewall part I wrote would be the same for both cases. The new session
config option would have to be written, but would be very similar - just take
the ip address from dbus value rather than interface's ip config.
One thing I am wondering about is if both options (interface's ip, and
user-provided ip) can be enabled at the same time. I think it is not a problem
- we can have multiple source ip rules in the firewall sending traffic to the
same routing table, set up by the session.
>
> Thanks,
> Daniel
------------------------------
Message: 3
Date: Mon, 23 Jan 2017 13:26:59 +0000
From: Lukasz Nowak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: HTTP GET usage for Ready to Online state transition
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
Currently, ConnMan uses an http get operation to transition a service from
Ready to Online state.
This is implemented in the wispr module, where a hard-coded http url is used:
#define STATUS_URL_IPV4 "http://ipv4.connman.net/online/status.html";
#define STATUS_URL_IPV6 "http://ipv6.connman.net/online/status.html";
Additionally, the http server must return a custom header in the reply:
"X-ConnMan-Status"
This is a problem for us, as we are planning to release a product, which must
not depend on the ConnMan's http server.
I think we need to make a change to add a config field, which allows the user
to:
- provide a custom http URL
- disable http get - automatically transition from Ready to Online state - let
the application detect the end-to-end connectivity
I am not sure what to do with the "X-ConnMan-Status" http reply header. Should
checking of it be disabled in case the config provides a URL from the user?
I realise that this functionality is also used to detect proxies, so I would
keep the current code as default, and provide an optional config field to
change wispr URL or disable it.
Does this make sense?
It is an issue we definitely have to address to use ConnMan. I would like to
make changes, which would be usable by others too.
Thanks.
Lukasz
------------------------------
Message: 4
Date: Mon, 23 Jan 2017 09:09:13 -0500
From: Daryl Nebrich <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Session policy with multiple AllowedBearers
Message-ID:
<CANmGHYuyzZjiqXsPx5xuZq=B5F=4ypu_ed4rkthih_d4qdn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
Using text mode now :)
On Sun, Jan 22, 2017 at 3:12 PM, Daniel Wagner <[email protected]> wrote:
> Hi Daryl,
>
> On 01/22/2017 08:33 PM, Daryl Nebrich wrote:
>>
>> Hi Daniel,
>>
>> Thanks for response. First post on the list. I'll try to reply inline
>> using gmail so I'm not top posting, hopefully comes out ok.
>
>
> Lot's of HTML I'd say.
>
>> @@ -1556,14 +1559,27 @@
>> enum connman_service_type bearer_type;
>> enum connman_service_type service_type;
>> GSList *list;
>> + bool current_service_connected;
>> + enum connman_service_type current_service_type;
>>
>> if (policy && policy->allowed)
>> return policy->allowed(session, service);
>>
>> + // Handle case where session policy has multiple AllowedBearers.
>> + // Check if current service in use is connected.
>> + current_service_connected =
>> __connman_service_is_connected_state(session->service,
>> CONNMAN_IPCONFIG_TYPE_IPV4);
>> + 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 the current service if found first (higher
>> priority)
>> + if (current_service_connected && (bearer_type ==
>> current_service_type)) {
>> + DBG("Keeping higher priority %s over %s",
>> __connman_service_type2string(current_service_type),
>> __connman_service_type2string(service_type));
>> + return false;
>> + }
>> +
>> if (bearer_type == service_type)
>> return true;
>> }
>>
>> But for the above to work, I also had to change the order of looping in
>> apply_policy_on_bearers(). At least in 1.33, the func loops through
>> available bearers first, and then policy bearers.
>
>
> That code is quite likely still the same. You could make a patch out of your
> work above. Your approach is better than mine, since you are addressing the
> ordering at the source.
>
>> Which means the order
>> of bearers in the policy file may not be preserved. For me, if I put
>> "cellular wifi" in the policy file, I would get "wifi cellular" as the
>> order in allowed_bearers. I think that change is still needed with your
>> approach above.
>
>
> As I said my snippet was just compile tested. So if you have something
> working, please share your patch. (btw, use /* */ then :))
>
>>
>> > I would expect it to always be wifi.
>>
>> Me too.
>>
>> > If the
>> > route is for cellular, and I manually bring down cellular, the
>> session
>> > will not revert to the wifi service (the route table stays empty).
>>
>> That is another bug I guess. Can you post the debug output part of
>> this?
>> This is supposed to work. BTW use the current HEAD for this. 1.33 is
>> pretty old :)
>>
>>
>> I fixed this by adding the below to handle_service_state_offline(). Not
>> sure if this is the right way but it tested ok for me.
>>
>> @@ -1695,6 +1711,9 @@
>>
>> session->service = NULL;
>> update_session_state(session);
>> +
>> + DBG("Try to find another service");
>> + session_activate(session);
>> }
>> }
>
>
> I have to admit I can't remember all the details in that file. Your change
> looks reasonable. If you can provide a short log attach that your patch and
> send it to reivew, that would be great!
>
>
>>
>>
>> > Shouldn't it revert? The logs show handle_service_state_offline()
>> > setting the session->service to null when cellular goes away. And
>> after
>> > that I'll get a "type wifi busy" log from the auto_connect_service()
>> > function in service.c. I see code in session.c to process the
>> policy
>> > bearers and setup allowed_bearers, but I'm not clear on where/how
>> it's used.
>>
>> Sorry about that messy code. It was quite difficult to get it
>> initially working
>> but it is for sure not really great code. If you find a way to
>> simplify
>> I am more than happy to take those patches.
>>
>>
>> Sorry, I wasn't suggesting that. I just hadn't spent the time to review
>> it enough. Things are working well now with the changes above.
>
>
> It was a long way to the current state, so I am glad that it starts to work.
>
>>
>> > I've reviewed the latest commits and see the change to nftables.
>> But I
>> > didn't see any code changes in session.c or session_local_policy.c
>> that
>> > might address this. Although I do see changes in service.c.
>>
>> Best thing for now is to use HEAD and port patches back if you need
>> to stay at
>> 1.33.
>>
>> > I'm
>> > building for an ARM (i.MX6) target using Yocto. And the NXP repos
>> are
>> > setup to use connman 1.30. I've updated to 1.33 and ported the
>> > patches. I can move to the tip if it would help.
>>
>> Sure. I'd like to see those kind of bugs gone. If you can provide some
>> logs I can try to figure out what is going wrong.
>>
>> Thanks,
>> Daniel
>>
>>
>> I'll back out my session_activate() change in
>> handle_service_state_offline() and reply later with a log.
>
>
> Cool. Thanks.
>
>> I'm a bit
>> hesitant to move to the tip now that I've got it going with iptables.
>
>
> Understood. If you have problems with iptables you might try nftables. At
> least it was really really easy to get it working compared to iptables. I
> have very strong feelings about iptables...
>
>> Do you know what the plans are for a 1.34 release?
>
>
> I have pinged Marcel about it a couple of times already. We really need 1.34
> release soon.
>
>> The bitbake recipe
>> is pulling down the code from kernel.org/pub/linux/network/connman
>> <http://kernel.org/pub/linux/network/connman>.
>
>
> Yep, yocto likes to do that :) Let's see if we can get Marcel to his magic
> to get a release!
>
> Thanks,
> Daniel
I've upgraded to the tip and attached log files for before and after my patches.
Patch 1 - I'm using ofono to create a PPP data connection. There's no
gateway reported by ofono in this case. So extract_ipv4_settings() in
plugins/ofono.c leaves gateway as null. Later,
session.c:add_default_route() fails. The patch I did was to default
the gateway to "0.0.0.0" in plugins/ofono.c. Not sure if the fix
should be there or in add_default_route().
Index: connman-9b07d2a/plugins/ofono.c
===================================================================
--- connman-9b07d2a.orig/plugins/ofono.c 2017-01-22 14:58:49.000000000 -0500
+++ connman-9b07d2a/plugins/ofono.c 2017-01-22 22:11:36.127307372 -0500
@@ -888,6 +888,11 @@
goto out;
}
+ /* Gateway not always returned by ofono. add_default_route()
fails if left as null. */
+ if (!gateway) {
+ gateway = g_strdup("0.0.0.0");
+ }
+
connman_ipaddress_set_ipv4(context->ipv4_address, address,
netmask, gateway);
I attached 2 log files showing before and after. For log 1, line 122
shows no gateway in ofono.c and line 192 is the add_default_route()
error. Log 2 has the fix with line 172 showing successful
add_default_route().
Patch 2 - Reorder AllowedBearers from the policy file and add
session_activate() to handle_service_state_offline().
Index: connman-9b07d2a/src/session.c
===================================================================
--- connman-9b07d2a.orig/src/session.c 2017-01-22 19:33:18.903307372 -0500
+++ connman-9b07d2a/src/session.c 2017-01-22 19:33:18.955307372 -0500
@@ -685,18 +685,18 @@
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;
@@ -709,15 +709,15 @@
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);
}
}
@@ -1548,15 +1548,24 @@
{
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;
+ }
+
if (bearer_type == service_type)
return true;
}
@@ -1688,6 +1697,9 @@
session->service = NULL;
update_session_state(session);
+
+ /* Check if another allowed bearer is available. */
+ session_activate(session);
}
}
One question I have with the above patch is if the connected status of
the current session service should be checked. Perhaps by calling
__connman_service_get_state to see if in online/ready state. Or if
it's enough for there to be a current session->service. In my
original patch earlier in the thread I called
__connman_service_is_connected_state. With that function you have to
specify IPV4/IPV6. Not sure of best way to handle that.
I attached 2 more log files (log 3 and 4) for before and after. Three
policies show up in the logs, conn1.policy is the one with
AllowedBearers = cellular wifi. The initial state is the session
using ppp0, I then disconnect cellular using connmanctl to test switch
to wifi. Log 3 shows handle_service_state_offline() on line 100 and
then wifi type busy on line 178. It doesn't switch to wifi. I then
add the patch above and log 4 shows successful switch. Line 164 is
handle_service_state_offline() and session_activate() is called on
line 181.
Let me know. I've also got another patch for specifying the cell APN
in the config file and passing it to the ofono plugin which then uses
set_property to update the ofono context. But I'll start a separate
thread on that.
Thanks,
Daryl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1_ofono_no_default_gateway_error.log
Type: application/octet-stream
Size: 25496 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20170123/1288cea4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2_ofono_with_default_gateway_fix.log
Type: application/octet-stream
Size: 27426 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20170123/1288cea4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3_no_wifi_switch_after_ppp_lost.log
Type: application/octet-stream
Size: 24533 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20170123/1288cea4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4_wifi_switch_after_ppp_lost_fix.log
Type: application/octet-stream
Size: 35046 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20170123/1288cea4/attachment-0003.obj>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 24
***************************************
