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. Query regarding cellular data connection with connman via
ofono (Naveen Kumar Danturi)
2. Re: Query regarding cellular data connection with connman via
ofono (Daryl Nebrich)
3. Re: Query regarding cellular data connection with connman via
ofono (Naveen Kumar Danturi)
4. Re: Query regarding cellular data connection with connman via
ofono (Daryl Nebrich)
5. Re: [RFC] Proposal for ConnMan session API extensions
(Daniel Wagner)
6. Re: Session policy with multiple AllowedBearers (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Tue, 24 Jan 2017 14:23:48 -0600
From: Naveen Kumar Danturi <[email protected]>
To: [email protected]
Subject: Query regarding cellular data connection with connman via
ofono
Message-ID:
<can3fbzzyqn0ijdohmolbrwdkosatvemysssq2wzs_cek87s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi experts,
After establishing a cellular data via particular apn, does user need to
explicitly update routing tables to make data traffic flow in the MNO
provided ip address route ? or will connman automatically updates once
ofono informs that cellular data connection is established ?
Really appreciate if some one can share the interactions/call flows between
connman/ofono for cellular connectivity.
Thanks,
Naveen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170124/8c8730f7/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 24 Jan 2017 15:32:57 -0500
From: Daryl Nebrich <[email protected]>
To: Naveen Kumar Danturi <[email protected]>
Cc: [email protected]
Subject: Re: Query regarding cellular data connection with connman via
ofono
Message-ID:
<CANmGHYsS72=NGU4Q8s=z8k6g1fjr+g+bxe2wf6qtz3wc0k2...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
Do you have multiple connections? I have both wifi and cellular. So,
yes, I had to setup the connman session policies to configure what
processes use which interface. The doc/session-policy-format.txt file
describes the policy files. You can setup AllowedBearers (wifi,
cellular, or both for example) and map them to a uid or gid. After
setting up the policies, be sure to enable the session-policy plugin
and then call the dbus session APIs to create the sessions. I
modified the test-session python script (installed to
/usr/lib/connman/test if enabled) to call the connman dbus session API
to create the sessions, which then load the policy files.
The end result is you get routing tables setup that are mapped to a
uid or gid. The latest code supports both iptables and nftables, I'm
using iptables. So I can run "iptables -S -t mangle" and see the uid
or gid marks setup. And then run "ip route show table 0x.." to view
the specific routing table.
And then of course you have to run the process using the uid or gid
you put in the session policy files.
Daryl
On Tue, Jan 24, 2017 at 3:23 PM, Naveen Kumar Danturi
<[email protected]> wrote:
> Hi experts,
> After establishing a cellular data via particular apn, does user need to
> explicitly update routing tables to make data traffic flow in the MNO
> provided ip address route ? or will connman automatically updates once
> ofono informs that cellular data connection is established ?
>
> Really appreciate if some one can share the interactions/call flows between
> connman/ofono for cellular connectivity.
>
> Thanks,
> Naveen
>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
>
------------------------------
Message: 3
Date: Tue, 24 Jan 2017 16:52:13 -0600
From: Naveen Kumar Danturi <[email protected]>
To: Daryl Nebrich <[email protected]>
Cc: [email protected]
Subject: Re: Query regarding cellular data connection with connman via
ofono
Message-ID:
<CAN3FBZb-tpu7n43VAiPP=9yKmOfTXawPf71dVgVX-Deo-=h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Actually we have just a cellular connection. So this means connman itself
cannot update routing tables?
Thanks,
Naveen
On Jan 24, 2017 2:32 PM, "Daryl Nebrich" <[email protected]> wrote:
Hi,
Do you have multiple connections? I have both wifi and cellular. So,
yes, I had to setup the connman session policies to configure what
processes use which interface. The doc/session-policy-format.txt file
describes the policy files. You can setup AllowedBearers (wifi,
cellular, or both for example) and map them to a uid or gid. After
setting up the policies, be sure to enable the session-policy plugin
and then call the dbus session APIs to create the sessions. I
modified the test-session python script (installed to
/usr/lib/connman/test if enabled) to call the connman dbus session API
to create the sessions, which then load the policy files.
The end result is you get routing tables setup that are mapped to a
uid or gid. The latest code supports both iptables and nftables, I'm
using iptables. So I can run "iptables -S -t mangle" and see the uid
or gid marks setup. And then run "ip route show table 0x.." to view
the specific routing table.
And then of course you have to run the process using the uid or gid
you put in the session policy files.
Daryl
On Tue, Jan 24, 2017 at 3:23 PM, Naveen Kumar Danturi
<[email protected]> wrote:
> Hi experts,
> After establishing a cellular data via particular apn, does user need to
> explicitly update routing tables to make data traffic flow in the MNO
> provided ip address route ? or will connman automatically updates once
> ofono informs that cellular data connection is established ?
>
> Really appreciate if some one can share the interactions/call flows
between
> connman/ofono for cellular connectivity.
>
> Thanks,
> Naveen
>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170124/500a3e28/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 24 Jan 2017 18:37:18 -0500
From: Daryl Nebrich <[email protected]>
To: Naveen Kumar Danturi <[email protected]>
Cc: [email protected]
Subject: Re: Query regarding cellular data connection with connman via
ofono
Message-ID:
<CANmGHYu+VXJaSOCzXZtzd0FyLVv2EYU6Xn9e0MVpGugNDgsG=q...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Then it's much simpler. With just a cellular data connection, connman
setup the routing table for me and everything just worked. Although
there was one issue. In my case, I have a PPP connection between the
app processor and the modem over a USB connection. So ofono didn't
populate the gateway with the information it passes to connman through
plugins/ofono.c. You can see the info with debug on in the
plugins/ofono.c file. I had to default the gateway to "0.0.0.0". You
may have to do the same. You can see my other thread about policies
and multiple bearers for more details.
Daryl
On Tue, Jan 24, 2017 at 5:52 PM, Naveen Kumar Danturi
<[email protected]> wrote:
> Actually we have just a cellular connection. So this means connman itself
> cannot update routing tables?
>
> Thanks,
> Naveen
>
> On Jan 24, 2017 2:32 PM, "Daryl Nebrich" <[email protected]> wrote:
>
> Hi,
>
> Do you have multiple connections? I have both wifi and cellular. So,
> yes, I had to setup the connman session policies to configure what
> processes use which interface. The doc/session-policy-format.txt file
> describes the policy files. You can setup AllowedBearers (wifi,
> cellular, or both for example) and map them to a uid or gid. After
> setting up the policies, be sure to enable the session-policy plugin
> and then call the dbus session APIs to create the sessions. I
> modified the test-session python script (installed to
> /usr/lib/connman/test if enabled) to call the connman dbus session API
> to create the sessions, which then load the policy files.
>
> The end result is you get routing tables setup that are mapped to a
> uid or gid. The latest code supports both iptables and nftables, I'm
> using iptables. So I can run "iptables -S -t mangle" and see the uid
> or gid marks setup. And then run "ip route show table 0x.." to view
> the specific routing table.
>
> And then of course you have to run the process using the uid or gid
> you put in the session policy files.
>
> Daryl
>
> On Tue, Jan 24, 2017 at 3:23 PM, Naveen Kumar Danturi
> <[email protected]> wrote:
>> Hi experts,
>> After establishing a cellular data via particular apn, does user need to
>> explicitly update routing tables to make data traffic flow in the MNO
>> provided ip address route ? or will connman automatically updates once
>> ofono informs that cellular data connection is established ?
>>
>> Really appreciate if some one can share the interactions/call flows
>> between
>> connman/ofono for cellular connectivity.
>>
>> Thanks,
>> Naveen
>>
>> _______________________________________________
>> connman mailing list
>> [email protected]
>> https://lists.01.org/mailman/listinfo/connman
>>
>
>
------------------------------
Message: 5
Date: Wed, 25 Jan 2017 07:28:20 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>, "Nakamura, Yusuke
(ADITJ/SWG)" <[email protected]>
Cc: "[email protected]" <[email protected]>, "Hoyer, Marko
(ADITG/SW2)" <[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; format=flowed
Hi
On 01/23/2017 02:05 PM, Lukasz Nowak wrote:
> On 22/01/17 19:47, Daniel Wagner wrote:
>> On 01/16/2017 02:00 PM, Nakamura, Yusuke (ADITJ/SWG) wrote:
>>> 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.
Yes, that is also my understanding.
> 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.
The proposal is talking about placing this information into the config
file only. I am assuming this proposal is about a static setup. Though
tracking updates from the config file isn't that hard.
> 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.
I haven't understood why the number of IP and the number of bearer is
connected to each other. The proposal text mention this and I am still
not getting it.
Thanks,
Daniel
------------------------------
Message: 6
Date: Wed, 25 Jan 2017 07:45:07 +0100
From: Daniel Wagner <[email protected]>
To: Daryl Nebrich <[email protected]>
Cc: [email protected], Lukasz Nowak <[email protected]>
Subject: Re: Session policy with multiple AllowedBearers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Daryl
On 01/23/2017 03:09 PM, Daryl Nebrich wrote:
> 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().
This sounds quite similarto the patch from Lukasz:
[PATCH v2 1/7] session: fix default route for ppp services
Lukasz addressed this in the session code which is more generic.
> 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;
This is just renaming here, right?
> @@ -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);
> }
> }
>
And here you swap the order of arguments to filter_bearer. Hmm, need to
ponder on what that means. I am rather careful here because I took quite
a while to come up with a somewhat understandable solution.
> @@ -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;
> + }
> +
This part looks good. Let me think about about the above changes and
what it means.
> 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);
> }
This is the second bug you were talking about, right?
> }
>
> 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.
So one standing problem is, that ConnMan does not do periodic online
checkes. Currently, it is only a one shot thing. Patrik argues that
doing it periodically is opening pandoras' box. Well I think we need to
do that eventually. You are not the first running into the exact problem.
> 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.
Unfortunately, I need to run again. Overall this looks like the right
direction.
> 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.
Cool, please post your patches into a nice series with proper commit
message etc.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 27
***************************************
