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: Using connman with multiple active interfaces (Patrik Flykt)
2. Re: Using connman with multiple active interfaces (Patrik Flykt)
3. [PATCH v2] service: Update nameservers automatically
(Patrik Flykt)
4. Re: Using connman with multiple active interfaces (Lukasz Nowak)
----------------------------------------------------------------------
Message: 1
Date: Fri, 04 Nov 2016 10:11:20 +0200
From: Patrik Flykt <[email protected]>
To: Lukasz Nowak <[email protected]>, Daniel Wagner
<[email protected]>, [email protected]
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-11-03 at 14:00 +0000, Lukasz Nowak wrote:
> So I had a good look at the sessions. If I understand correctly,
> each session sets an iproute2 rule to forward packets
> with a session-specific fwmark to the correct routing table.
> The marks are added with iptables based on UID, GID or SELINUX.
>
> This is quite a bit off from what we need: having one application
> freely choosing which interface to send traffic through.
IIRC sessions are also ending up with only one default route. This has
been the current best practise so far. But that does not mean it cannot
be changed. The user expectation when connecting to a WiFi is that
traffic moves over to WiFi from e.g. cellular; with this in mind the
corner case then is whether a connection is still kept on cellular or
whether it is to break and re-establish itself over WiFi.
> Firstly, can a single application connect multiple sessions?
> (one for each interface)
The code seems to be happy with multiple sessions being created.
> Even if yes, all the sessions would then receive the same policy,
> so only one iptables marking entry would be active, i.e. only
> one routing table would be used. The application would not have
> a way to change that.
>
> Also, if I understand correctly, if an application opens a session
> with a UID/GID policy, the iptables/iproute rules will immediately
> affect all processes with the same UID/GID - is that correct?
Yes. So something additional is needed as the first UID, GID or Selinux
rule matches.
> Ideally, what we need would is either:
> - set an iproute2 rule to use correct routing table based on packet
> source ip
> - use iptables to mark packets based on source ip
>
> In either case, I cannot see how it can be easily added to the
> policy model. Unless the application could choose a specific policy
> when creating a session.
>
>
> For the AlwaysConnectedTechnologies: this change does not do
> a lot. We can achieve the same effect by the application manually
> connecting all services. In either case, the routing table will
> only be established for one service. So the services in Ready
> state will not be usable for sending external traffic.
This is the first step towards connecting more than one service
automatically; the same will be achieved right now by connecting every
other service manually.
> Automatically adding additional routing tables for each
> AlwaysConnectedTechnology,
> and iproute2 rules based on source ip, would do the job. But it?
> would have to be independent of the Sessions.
That'd be the next issue to sort out.
Cheers,
Patrik
------------------------------
Message: 2
Date: Fri, 04 Nov 2016 10:22:47 +0200
From: Patrik Flykt <[email protected]>
To: Dragos Tatulea <[email protected]>, Lukasz Nowak
<[email protected]>
Cc: Daniel Wagner <[email protected]>, [email protected], Dragos
Tatulea <[email protected]>
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-11-03 at 18:06 +0100, Dragos Tatulea wrote:
> I haven't spent any time into cleaning these up because I was under
> the impresion that they weren't interesting enough for upstreaming.
> Although the patchest is quite large, some things are not required
> and the service part is the easiest.
>
> I could clean them up and send them over if you would be interested
> in reviewing and testing them.
Let's star off by getting AlwaysConnectedTechnology added first. Then
figure out with an RFC patch if one needs to add per interface routing
tables to get a default route for each interface or if there are other
means for ConnMan to make it work. At that point the "default" policy
of switching all traffic from cellular to WiFi is most likely affected;
the current assumption is that all "normal" traffic uses the service
with the highest priority (i.e. the first one).
Did your patch set have a solution for differentiation specific (MPTCP)
traffic and the generic traffic that is supposed to use the most
preferred service for its traffic?
Cheers,
Patrik
------------------------------
Message: 3
Date: Fri, 4 Nov 2016 11:38:32 +0200
From: Patrik Flykt <[email protected]>
To: [email protected]
Subject: [PATCH v2] service: Update nameservers automatically
Message-ID: <[email protected]>
Automatically update nameserver information when they are appended
or removed to the resolver code so that nameservers for IPv6 can be
signalled after IPv4 has moved the service to state 'ready'. Create
a zero second timeout so that nameservers can be appended or removed
in a loop one by one with only one D-Bus PropertyChanged signal
being sent.
Verify that the service is either connected or the nameservers have
been removed when the service is inactive before sending the
PropertyChanged signal.
---
v2: Move nameserver announcing to the updating of the resolver. This
should take care of adding IPv6 nameservers after the service is
in state 'ready'.
Please test,
Patrik
src/service.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/src/service.c b/src/service.c
index f6a76f6..1d65410 100644
--- a/src/service.c
+++ b/src/service.c
@@ -92,6 +92,7 @@ struct connman_service {
char **nameservers;
char **nameservers_config;
char **nameservers_auto;
+ int nameservers_timeout;
char **domains;
char *hostname;
char *domainname;
@@ -133,6 +134,7 @@ static struct connman_ipconfig *create_ip4config(struct
connman_service *service
int index, enum connman_ipconfig_method method);
static struct connman_ipconfig *create_ip6config(struct connman_service
*service,
int index);
+static void dns_changed(struct connman_service *service);
struct find_data {
const char *path;
@@ -922,6 +924,24 @@ static bool is_connected_state(const struct
connman_service *service,
return false;
}
+static bool is_idle(struct connman_service *service)
+{
+ switch (service->state) {
+ case CONNMAN_SERVICE_STATE_IDLE:
+ case CONNMAN_SERVICE_STATE_DISCONNECT:
+ case CONNMAN_SERVICE_STATE_FAILURE:
+ return true;
+ case CONNMAN_SERVICE_STATE_UNKNOWN:
+ case CONNMAN_SERVICE_STATE_ASSOCIATION:
+ case CONNMAN_SERVICE_STATE_CONFIGURATION:
+ case CONNMAN_SERVICE_STATE_READY:
+ case CONNMAN_SERVICE_STATE_ONLINE:
+ break;
+ }
+
+ return false;
+}
+
static bool is_connecting(struct connman_service *service)
{
return is_connecting_state(service, service->state);
@@ -932,6 +952,29 @@ static bool is_connected(struct connman_service *service)
return is_connected_state(service, service->state);
}
+
+static int nameservers_changed_cb(void *user_data)
+{
+ struct connman_service *service = user_data;
+
+ DBG("service %p", service);
+
+ service->nameservers_timeout = 0;
+ if ((is_idle(service) && !service->nameservers) ||
+ is_connected(service))
+ dns_changed(service);
+
+ return FALSE;
+}
+
+static void nameservers_changed(struct connman_service *service)
+{
+ if (!service->nameservers_timeout)
+ service->nameservers_timeout = g_timeout_add_seconds(0,
+ nameservers_changed_cb,
+ service);
+}
+
static bool nameserver_available(struct connman_service *service,
enum connman_ipconfig_type type,
const char *ns)
@@ -1011,7 +1054,7 @@ static int nameserver_add(struct connman_service *service,
enum connman_ipconfig_type type,
const char *nameserver)
{
- int index;
+ int index, ret;
if (!nameserver_available(service, type, nameserver))
return 0;
@@ -1020,7 +1063,11 @@ static int nameserver_add(struct connman_service
*service,
if (index < 0)
return -ENXIO;
- return connman_resolver_append(index, NULL, nameserver);
+ ret = connman_resolver_append(index, NULL, nameserver);
+ if (ret >= 0)
+ nameservers_changed(service);
+
+ return ret;
}
static int nameserver_add_all(struct connman_service *service,
@@ -1054,7 +1101,7 @@ static int nameserver_remove(struct connman_service
*service,
enum connman_ipconfig_type type,
const char *nameserver)
{
- int index;
+ int index, ret;
if (!nameserver_available(service, type, nameserver))
return 0;
@@ -1063,7 +1110,11 @@ static int nameserver_remove(struct connman_service
*service,
if (index < 0)
return -ENXIO;
- return connman_resolver_remove(index, NULL, nameserver);
+ ret = connman_resolver_remove(index, NULL, nameserver);
+ if (ret >= 0)
+ nameservers_changed(service);
+
+ return ret;
}
static int nameserver_remove_all(struct connman_service *service,
@@ -1139,6 +1190,8 @@ int __connman_service_nameserver_append(struct
connman_service *service,
nameserver_add(service, CONNMAN_IPCONFIG_TYPE_ALL, nameserver);
}
+ nameservers_changed(service);
+
searchdomain_add_all(service);
return 0;
@@ -4500,6 +4553,11 @@ static void service_free(gpointer user_data)
reply_pending(service, ENOENT);
+ if (service->nameservers_timeout) {
+ g_source_remove(service->nameservers_timeout);
+ dns_changed(service);
+ }
+
__connman_notifier_service_remove(service);
service_schedule_removed(service);
@@ -5440,7 +5498,6 @@ static int service_indicate_state(struct connman_service
*service)
g_get_current_time(&service->modified);
service_save(service);
- dns_changed(service);
domain_changed(service);
proxy_changed(service);
@@ -5481,7 +5538,6 @@ static int service_indicate_state(struct connman_service
*service)
__connman_wpad_stop(service);
- dns_changed(service);
domain_changed(service);
proxy_changed(service);
--
2.10.1
------------------------------
Message: 4
Date: Fri, 4 Nov 2016 11:30:59 +0000
From: Lukasz Nowak <[email protected]>
To: Patrik Flykt <[email protected]>, Daniel Wagner
<[email protected]>, [email protected]
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Just to be clear, we are not looking for changing the logic of the main
routing table. That works fine. We are looking at having the
default routes in the additional routing tables, and filtering traffic
to them based on application's explicit request.
I had a look at the session code, and I think this could be relatively
easily added to the session config functionality, rather than to policy.
Session config currently has "bearers" and "type" fields.
We could add "ifname" and "source_route" options.
"ifname" would specify which service should be used (based on if name, e.g.
eth0).
This would be an AND with "bearers". And source route would be a boolean
which would add a iproute2 rule for interface's src ip address.
This way, any standard socket, not bound to any interface ip would use the
main routing table, and if application does bind(ip) before connect(),
it would use the alternative routing table set up by a session.
This looks like a reasonably small change in session.c and inet.c (to add the
src iprule).
Lukasz
On 04/11/16 08:11, Patrik Flykt wrote:
> On Thu, 2016-11-03 at 14:00 +0000, Lukasz Nowak wrote:
>> So I had a good look at the sessions. If I understand correctly,
>> each session sets an iproute2 rule to forward packets
>> with a session-specific fwmark to the correct routing table.
>> The marks are added with iptables based on UID, GID or SELINUX.
>>
>> This is quite a bit off from what we need: having one application
>> freely choosing which interface to send traffic through.
>
> IIRC sessions are also ending up with only one default route. This has
> been the current best practise so far. But that does not mean it cannot
> be changed. The user expectation when connecting to a WiFi is that
> traffic moves over to WiFi from e.g. cellular; with this in mind the
> corner case then is whether a connection is still kept on cellular or
> whether it is to break and re-establish itself over WiFi.
>
>> Firstly, can a single application connect multiple sessions?
>> (one for each interface)
>
> The code seems to be happy with multiple sessions being created.
>
>> Even if yes, all the sessions would then receive the same policy,
>> so only one iptables marking entry would be active, i.e. only
>> one routing table would be used. The application would not have
>> a way to change that.
>>
>> Also, if I understand correctly, if an application opens a session
>> with a UID/GID policy, the iptables/iproute rules will immediately
>> affect all processes with the same UID/GID - is that correct?
>
> Yes. So something additional is needed as the first UID, GID or Selinux
> rule matches.
>
>> Ideally, what we need would is either:
>> - set an iproute2 rule to use correct routing table based on packet
>> source ip
>> - use iptables to mark packets based on source ip
>>
>> In either case, I cannot see how it can be easily added to the
>> policy model. Unless the application could choose a specific policy
>> when creating a session.
>>
>>
>> For the AlwaysConnectedTechnologies: this change does not do
>> a lot. We can achieve the same effect by the application manually
>> connecting all services. In either case, the routing table will
>> only be established for one service. So the services in Ready
>> state will not be usable for sending external traffic.
>
> This is the first step towards connecting more than one service
> automatically; the same will be achieved right now by connecting every
> other service manually.
>
>> Automatically adding additional routing tables for each
>> AlwaysConnectedTechnology,
>> and iproute2 rules based on source ip, would do the job. But it
>> would have to be independent of the Sessions.
>
> That'd be the next issue to sort out.
>
> Cheers,
>
> Patrik
>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 13, Issue 4
**************************************
