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 2/7] session: add allowed interface config
parameter (Daniel Wagner)
2. Re: [PATCH v2 7/7] doc: session multi-interface routing
(Daniel Wagner)
3. Re: [PATCH v2 0/7] session: add per-interface routing
(Daniel Wagner)
4. Re: [PATCH] service: Replace g_timeout_add_seconds() with
g_idle_add() (Daniel Wagner)
5. Re: Session policy with multiple AllowedBearers (Daniel Wagner)
6. Re: Confusion about ublox toby-L2 IP configuration (Daniel Wagner)
7. Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sun, 22 Jan 2017 17:45:39 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [PATCH v2 2/7] session: add allowed interface config
parameter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
On 01/17/2017 10:17 AM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> In order to be able to bind a session to a specific interface,
> a config option has been added. It is supported through both
> dbus and session policy. Policy always overrides dbus.
'config option has been added': That is with this patch, right? Maybe
mention that you are added AllowedInterface which does following
things... bla bla
> This is the first step to implement per-interface routing.
> Next step will be to add src ip rules to iptables, which
> will allow the application to transmit through multiple
> interfaces.
I think you can leave that information away. This is something for the
cover letter.
> connman_session_parse_connection_type(val));
> + } else if (g_str_equal(name, "AllowedInterface")) {
> + dbus_message_iter_get_basic(&value, &val);
> + if (session->active)
> + set_active_session(session, false);
> +
> + session->active = false;
> + session_deactivate(session);
> +
> + g_free(session->user_allowed_interface);
> + /* empty string means allow any interface */
> + if (0 == g_strcmp0(val, ""))
> + session->user_allowed_interface = NULL;
> + else
> + session->user_allowed_interface = g_strdup(val);
> +
> + info->config.allowed_interface =
> apply_policy_on_interface(
> + session->policy_config->allowed_interface,
> + session->user_allowed_interface);
> +
> + session_activate(session);
> } else {
> goto err;
> }
For AllowedBearer we have 'any' as match any available bearer. If the
string is empty it means no bearer is allowed. I wonder if we should
follow the AllowedBearer approach to keep it more consistent.
The rest looks good to me.
Thanks,
Daniel
------------------------------
Message: 2
Date: Sun, 22 Jan 2017 18:03:09 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH v2 7/7] doc: session multi-interface routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
On 01/17/2017 10:17 AM, [email protected] wrote:
> 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 | 22 ++++++++++++++++++++++
> doc/session-overview.txt | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 53 insertions(+)
>
> diff --git a/doc/session-api.txt b/doc/session-api.txt
> index 3aac535..42766e7 100644
> --- a/doc/session-api.txt
> +++ b/doc/session-api.txt
> @@ -182,3 +182,25 @@ Settings string State [readonly]
> (This setting will be removed when the unique process
> identification problem is solved.)
>
> + string AllowedInterface [readwrite]
> +
> + 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.
> +
> + 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]
> +
> + 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.
nitpick s/ip/IP ?
And if I read it correctly it is only IPv4, correct? Hmm, the whole
firewall code is not IPv6 ready... another todo on my list...
cheers,
daniel
> diff --git a/doc/session-overview.txt b/doc/session-overview.txt
> index 2393167..a18600d 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.
>
------------------------------
Message: 3
Date: Sun, 22 Jan 2017 19:04:29 +0100
From: Daniel Wagner <[email protected]>
To: [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; format=flowed
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: 4
Date: Sun, 22 Jan 2017 19:09:59 +0100
From: Daniel Wagner <[email protected]>
To: Saurav Babu <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH] service: Replace g_timeout_add_seconds() with
g_idle_add()
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Saurav,
On 01/16/2017 09:45 AM, Saurav Babu wrote:
> 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."
I am fine with this change. Though we have few more of those (not sure if
my grep-foo got all of them):
src/dhcpv6.c: dhcp->timeout = g_timeout_add_seconds(0,
start_rebind,
src/peer.c: g_timeout_add_seconds(0, dhcp_server_started,
connman_peer_ref(peer));
src/proxy.c: lookup->watch = g_timeout_add_seconds(0, lookup_callback,
lookup);
src/service.c: service->nameservers_timeout = g_timeout_add_seconds(0,
src/service.c: autoconnect_timeout = g_timeout_add_seconds(0, run_auto_connect,
src/service.c: g_timeout_add_seconds(0, run_vpn_auto_connect, NULL);
src/task.c: g_timeout_add_seconds(0, check_kill,
src/wispr.c: g_timeout_add_seconds(0, no_proxy_callback,
wp_context);
So changing just one is okay but change all of them would great. Would you mind
to prepare a patch set which changes all of them?
Thanks a lot,
Daniel
------------------------------
Message: 5
Date: Sun, 22 Jan 2017 19:46:09 +0100
From: Daniel Wagner <[email protected]>
To: Daryl Nebrich <[email protected]>, [email protected]
Subject: Re: Session policy with multiple AllowedBearers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Daryl
On 01/20/2017 07:45 PM, Daryl Nebrich wrote:
> Hi,
>
> I'm running version 1.33 with the local policy plugin enabled. I have 3
> policies setup, first with AllowedBearers set to "wifi", second with
> "cellular" and the third with "wifi cellular", each set to a unique
> uid. The session-api.txt doc states that the order is important as it
> sets priority. The issue I'm seeing is with the 3rd policy having both
> wifi and cellular. I have a python script creating the sessions. The
> nat and mangle tables are setup right and I've verified the routing
> table using ip route show table 0x..
>
> Both wifi and cellular services are up. The issue is that the session
> using policy 3 will sometimes initially create a default route for
> wifi, sometimes cellular.
The order of connection up event of the services is probably the source
of the problem. That is if wifi gets up first that one will the default
route. And if cellular is first, that's the default route. If that is
the case there is bug in the session code.
static void handle_service_state_online(struct connman_service *service,
enum connman_service_state state,
struct connman_service_info *info)
{
GHashTableIter iter;
gpointer key, value;
g_hash_table_iter_init(&iter, session_hash);
while (g_hash_table_iter_next(&iter, &key, &value)) {
struct connman_session *session = value;
bool connected;
connected = is_session_connected(session, state);
if (session->service == service) {
if (!connected) {
DBG("session %p remove service %p", session,
service);
info->sessions = g_slist_remove(info->sessions,
session);
session->service = NULL;
update_session_state(session);
}
} else if (connected && session_match_service(session,
service)) {
DBG("session %p add service %p", session, service);
info->sessions = g_slist_prepend(info->sessions,
session);
session->service = service; // here
is the problem I think
update_session_state(session);
}
}
}
That should probably not just assigning the new service We need to check
the AllowedBearers too.
Can you try this here (only compile tested)
diff --git a/src/session.c b/src/session.c
index b1e9e1b..fd4be2b 100644
--- a/src/session.c
+++ b/src/session.c
@@ -721,6 +721,25 @@ static void apply_policy_on_bearers(GSList
*policy_bearers, GSList *bearers,
}
}
+static unsigned int position_in_bearers(GSList *policy_bearers,
+ struct connman_service *service)
+{
+ enum connman_service_type bearer;
+ GSList *it;
+ unsigned int pos = 0;
+
+ for (it = policy_bearers; it; it = it->next) {
+ bearer = GPOINTER_TO_INT(it->data);
+
+ if (bearer == connman_service_get_type(service))
+ return pos;
+
+ pos++;
+ }
+
+ return pos;
+}
+
const char *connman_session_get_owner(struct connman_session *session)
{
return session->owner;
@@ -1664,6 +1683,21 @@ static void handle_service_state_online(struct
connman_service *service,
info->sessions = g_slist_prepend(info->sessions,
session);
+
+ if (session->service) {
+ unsigned int pos_old;
+ unsigned int pos_new;
+
+ pos_old = position_in_bearers(
+ session->info->config.allowed_bearers,
+ session->service);
+ pos_new = position_in_bearers(
+ session->info->config.allowed_bearers,
+ service);
+
+ if (pos_old < pos_new)
+ return;
+ }
session->service = service;
update_session_state(session);
}
> 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
:)
> 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.
> 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
------------------------------
Message: 6
Date: Sun, 22 Jan 2017 20:02:33 +0100
From: Daniel Wagner <[email protected]>
To: Eric Grunt <[email protected]>, [email protected]
Subject: Re: Confusion about ublox toby-L2 IP configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Eric,
On 01/20/2017 05:02 PM, Eric Grunt wrote:
> In interaction with ofono 1.18, connman 1.33 configures IPs for ublox
> toby-L2 like this:
>
> /*
> +UIPADDR: 1,"usb0:0","10.230.77.23","255.255.255.255","",""
> +CGCONTRDP: 1,0,"event.vodafone.de
> <http://event.vodafone.de>","10.230.77.232.255.255.255.255","10.230.77.232","139.7.30.125","139.7.30.126","0.0.0.0","0.0.0.0",0
> */
>
> wwan0 Link encap:Ethernet HWaddr b6:90:aa:61:a0:79
> inet addr:10.230.77.232 Bcast:10.230.77.232 Mask:255.255.255.255
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:6 errors:0 dropped:0 overruns:0 frame:0
> TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:384 (384.0 B) TX bytes:908 (908.0 B)
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 0.0.0.0 10.230.77.232 0.0.0.0 UG 0 0 0
> wwan0
> 10.230.77.232 0.0.0.0 255.255.255.255 UH 0 0 0
> wwan0
> 139.7.30.125 10.230.77.232 255.255.255.255 UGH 0 0 0
> wwan0
> 139.7.30.126 10.230.77.232 255.255.255.255 UGH 0 0 0
> wwan0
>
> So it basically configures itself as gateway for everything
> and also writes 139.7.30.125 and 139.7.30.126 to the routing table,
> alltough those are supposed to be used for dns resolution.
> With the configuration above, neither pinging the ublox router
> (192.168.1.1) nor the outside internet (8.8.8.8) is working (100%
> packet loss)
Can you post what oFono tells ConnMan? I think that would be the output
of ofono/test/list-contexts. It sounds like ConnMan gets something
wrong. Also the debug output of the ofono plugin would be great, e.g.
connmand -n -d plugins/ofono.c
> While the ublox NetworkingModes Manual [1] considers the IP returned
> with UIPADDR as to be used as gateway (when using ublox in bridged mode)
> ofono does not even query it.
> ofono also configures ublox actively into bridging mode (while it
> states, that it does not yet support router mode).
>
> Is the above configuration supposed to work with toby-L2 in bridging mode?
> If so, could you give me a hint what might have gone wrong?
I haven't played with those toby-L2 devices. Just looked quickly at a
PDF [1]. I guess you are referring to Figure 3 and 4? At least 3 should
work.
> When attempting a manual configuration (using the same AT commands as
> ofono [2]), pinging the outside internet is possible, allthough the fun
> does not last very long (few minutes).
> (additionally pinging the ublox router only works when using ip aliases
> like described in [1], which connman doesn't seem to support)
>
> ifconfig wwan0 10.230.77.232 netmask 255.255.255.255 pointopoint
> 10.230.77.23 up
> route add default gw 10.230.77.23
>
> results in
>
> wwan0 Link encap:Ethernet HWaddr 62:dd:4b:67:6c:00
> inet addr:10.249.48.81 Bcast:10.255.255.255 Mask:255.255.255.255
> inet6 addr: fe80::60dd:4bff:fe67:6c00/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:5 errors:0 dropped:0 overruns:0 frame:0
> TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:308 (308.0 B) TX bytes:772 (772.0 B)
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 0.0.0.0 10.249.48.174 0.0.0.0 UG 0 0 0
> wwan0
> 10.249.48.174 0.0.0.0 255.255.255.255 UH 0 0 0
> wwan0
From what you describe it looks like oFono is giving ConnMan some wrong
information. But that is just a guess. If you can provide the logs from
ConnMan and oFono that would be really helpful.
cheers,
daniel
------------------------------
Message: 7
Date: Sun, 22 Jan 2017 20:04:47 +0100
From: Daniel Wagner <[email protected]>
To: Shrikant Bobade <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
> observed during regression, there was no further hang using
> GNUTLS_NO_EXPLICIT_INIT=1,
> using it resolves the issue.
Excellent. Okay, now we know what happens. I'll add it to my todo list
to fix those urandom users in ConnMan and also the documentation needs
to be updated.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 21
***************************************
