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] gsupplicant: Avoid skipping wpa_supplicant
interfaces (Patrik Flykt)
2. Re: Query about Connman Session (Daniel Wagner)
3. Re: [PATCH] gsupplicant: Avoid skipping wpa_supplicant
interfaces (Jose Blanquicet)
4. [PATCH][v2] gsupplicant: Avoid skipping wpa_supplicant
interfaces (Jose Blanquicet)
5. Re: [PATCH] connman.service: Use ProtectSystem=true to allow
writing /etc/localtime (Patrik Flykt)
6. Re: [PATCH] dhcpv6: use correct dhcp renew time when valid
life-time is infinity. (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Wed, 13 Jul 2016 10:31:01 +0300
From: Patrik Flykt <[email protected]>
To: Jose Blanquicet <[email protected]>, [email protected]
Subject: Re: [PATCH] gsupplicant: Avoid skipping wpa_supplicant
interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Tue, 2016-07-12 at 18:06 +0200, Jose Blanquicet wrote:
> If the wpa_supplicant has been launched before ConnMan, when the Connman?
> calls the GetAll method on fi.w1.wpa_supplicant1, the properties are?
> returned as an array where there is an entry named "Interfaces". This?
> entry is an array itself with only the object path of the current?
> available interfaces. The problem occurs when ConnMan goes across this?
> array using the function interface_added(), because this function tries?
> also to extract the interface properties next to object path which is?
> wrong because properties are not appended in this message reply. So, by?
> doing dbus_message_iter_next(iter), we are actually skipping one interface?
> of the list and it will result in a future error because the skipped?
> interface(s) were not stored and ConnMan will not be aware of them.
>
> This issue is due to the function interface_added() is also used when?
> signal "fi.w1.wpa_supplicant1.InterfaceAdded" arrives, and in this?
> message the properties are actually appended. This patch aims to solve?
> this issue by distinguishing the caller to avoid trying to extract?
> properties if they are not appended in the message.
>
> ---
> ?gsupplicant/supplicant.c | 20 ++++++++++++--------
> ?1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
> index 09a3ac5..5a038d1 100644
> --- a/gsupplicant/supplicant.c
> +++ b/gsupplicant/supplicant.c
> @@ -2320,6 +2320,7 @@ static void interface_added(DBusMessageIter *iter, void
> *user_data)
> ?{
> ? GSupplicantInterface *interface;
> ? const char *path = NULL;
> + unsigned int properties_appended = GPOINTER_TO_UINT(user_data);
> ?
> ? SUPPLICANT_DBG("");
> ?
> @@ -2338,18 +2339,20 @@ static void interface_added(DBusMessageIter *iter,
> void *user_data)
> ? if (!interface)
> ? return;
> ?
> + if (properties_appended == 0) {
It is preferred to write this as !properties_appended
> + supplicant_dbus_property_get_all(path,
> + SUPPLICANT_INTERFACE
> ".Interface",
> + interface_property, interface,
> + interface);
> + return;
> + }
> +
> ? dbus_message_iter_next(iter);
> ? if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INVALID) {
> ? supplicant_dbus_property_foreach(iter, interface_property,
> ? interface);
> ? interface_property(NULL, NULL, interface);
> - return;
> ? }
> -
> - supplicant_dbus_property_get_all(path,
> - SUPPLICANT_INTERFACE ".Interface",
> - interface_property, interface,
> - interface);
> ?}
> ?
> ?static void interface_removed(DBusMessageIter *iter, void *user_data)
> @@ -2409,7 +2412,8 @@ static void service_property(const char *key,
> DBusMessageIter *iter,
> ? dbus_message_iter_get_basic(iter, &debug_showkeys);
> ? SUPPLICANT_DBG("Debug show keys %u", debug_showkeys);
> ? } else if (g_strcmp0(key, "Interfaces") == 0) {
> - supplicant_dbus_array_foreach(iter, interface_added, NULL);
> + supplicant_dbus_array_foreach(iter, interface_added,
> + GUINT_TO_POINTER((unsigned int)
> false));
The original?supplicant_dbus_array_foreach(iter, interface_added,
NULL); works so it does not need changing.
> ? } else if (g_strcmp0(key, "EapMethods") == 0) {
> ? supplicant_dbus_array_foreach(iter, eap_method, NULL);
> ? debug_strvalmap("EAP method", eap_method_map, eap_methods);
> @@ -2479,7 +2483,7 @@ static void signal_interface_added(const char *path,
> DBusMessageIter *iter)
> ? SUPPLICANT_DBG("path %s %s", path, SUPPLICANT_PATH);
> ?
> ? if (g_strcmp0(path, SUPPLICANT_PATH) == 0)
> - interface_added(iter, NULL);
> + interface_added(iter, GUINT_TO_POINTER((unsigned int) true));
A GUINT_TO_POINTER(true) seems to be enough here.
> ?}
>
> ?
> ?static void signal_interface_removed(const char *path, DBusMessageIter *iter)
Cheers,
Patrik
------------------------------
Message: 2
Date: Wed, 13 Jul 2016 10:28:40 +0200
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, Benjamin Ioller
<[email protected]>, [email protected]
Subject: Re: Query about Connman Session
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Sorry for the late response. Overlooked it.
On 07/12/2016 03:40 PM, Patrik Flykt wrote:
> On Thu, 2016-06-30 at 15:05 +0200, Benjamin Ioller wrote:
>> Does someone use the Connman's session? and for which application?
Yes, I do, though I can't share the application :)
>> Can you give me an example?
You can start on the first shell the test application. From
the second shell you can send the commands, e.g.
Shell 1:
$ ./test-session run /foo
connman appeared on D-Bus :1.6
Create session
notify path /foo/bar
session path /sessions/_1_33747/foo/bar
Update called at /foo/bar
AllowedBearers = [ ethernet ]
Bearer = ethernet
ConnectionType = any
State = online
IPv4 = { Netmask=255.255.254.0 Gateway=10.10.50.1 Method=dhcp
Address=10.10.50.51 }
IPv6 = { }
Interface = eth0
Name = Wired
Shell 2:
$ ./test-session create /foo bar
>> So here is what I understood so far about the session mode:
>> Connman session allows the application to use specific network
>> setting as selected technologies, roaming policy...
>> Connman uses Iptable to do so. Connman creates rules in the mangle
>> table to mark the packet based on the UID/GID.
>> Then rules are added to the filter table depending on the allowed
>> bearers, and other properties.
>> This routing is only functional when the connman state option is ON.
>
> If you mean Manager API SessionMode boolean property, that one does
> nothing. Sessions are nowadays always available and active as soon as
> someone calls CreateSession().
The SessionMode is a left over. First we wanted to have it only
enabled when SessionMode is set. Though it turned out that it is
useless. We can't remove it without breaking the D-Bus API. It will
go when ConnMan 2.x starts to exist.
>> Connman proposes two ways to create a session :
>> First, the application creates it's own session using the method
>> form /net.connman.manager. I try to use this method with a python
>> script, the application creates a session, connects to it and sends
>> UDP packet to a local host via ethernet. But I didn't manage to setup
>> the AllowedBearers, neither with
>> manager.CreateSession({"AllowedBearers":Glib.Variant('s','ethernet')}
>> ,notifier_path)
>> nor
>> Session.Change("AllowedBeares",Glib.Variant('s','ethernet')).
>> I have Variant encoding issue. Do you have any advice or exemple?
>
> See the python code in test/test-session, it should work.
Yes test/test-session should work *fingers crossed*.
>> The second way is to use session_policy. With this method you can
>> mark packet only based on the UID or GID. I need to create UID.policy
>> in var/lib/connman/session_policy_local which contained the different
>> parameters.
The D-Bus API doesn't expose all session features. Some of them are
only available via the config files. For example one of mine looks
like this:
$ cat /var/lib/connman/session_policy_local/cmtest.policy
[default_policy]
uid=cmtest
AllowedBearers = wifi
The config file overwrites the D-Bus configuration. In the above example
only Wifi is allowed in the D-Bus API.
> With a policy plugin one can fine tune what parameters in
> CreateSession() calls are allowed. No policy module, no constraints for
> CreateSession() (IIRC, or that was the intention).
The provided local policy plugin is just one simple example how to
steer the sessions. For example you don't like the above local policy
config stuff, have can create your own plugin.
> The provided session
> policy is just a simple example, one can create a new policy module
> containing more code and get something fancy as a policy decision
> instead of reading a simple file.
Yep. I have created a more sophisticated one which can find here:
http://git.projects.genivi.org/?p=pold.git;a=blob;f=connman/0001-session_policy_pold-Add-session-plugin-for-remote-co.patch;h=b85a6377468b81b367c31a430e7d56e919d92956;hb=HEAD
This one also controls the bearer selection.
cheers,
daniel
------------------------------
Message: 3
Date: Wed, 13 Jul 2016 11:11:35 +0200
From: Jose Blanquicet <[email protected]>
To: [email protected]
Subject: Re: [PATCH] gsupplicant: Avoid skipping wpa_supplicant
interfaces
Message-ID:
<cafc8ijjn2skmnd97fxfmc9f8wpeeczht-pzpovausbu1svu...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
On Wed, Jul 13, 2016 at 9:31 AM, Patrik Flykt
<[email protected]> wrote:
>
> Hi,
>
> On Tue, 2016-07-12 at 18:06 +0200, Jose Blanquicet wrote:
>> If the wpa_supplicant has been launched before ConnMan, when the Connman
>> calls the GetAll method on fi.w1.wpa_supplicant1, the properties are
>> returned as an array where there is an entry named "Interfaces". This
>> entry is an array itself with only the object path of the current
>> available interfaces. The problem occurs when ConnMan goes across this
>> array using the function interface_added(), because this function tries
>> also to extract the interface properties next to object path which is
>> wrong because properties are not appended in this message reply. So, by
>> doing dbus_message_iter_next(iter), we are actually skipping one interface
>> of the list and it will result in a future error because the skipped
>> interface(s) were not stored and ConnMan will not be aware of them.
>>
>> This issue is due to the function interface_added() is also used when
>> signal "fi.w1.wpa_supplicant1.InterfaceAdded" arrives, and in this
>> message the properties are actually appended. This patch aims to solve
>> this issue by distinguishing the caller to avoid trying to extract
>> properties if they are not appended in the message.
>>
>> ---
>> gsupplicant/supplicant.c | 20 ++++++++++++--------
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
>> index 09a3ac5..5a038d1 100644
>> --- a/gsupplicant/supplicant.c
>> +++ b/gsupplicant/supplicant.c
>> @@ -2320,6 +2320,7 @@ static void interface_added(DBusMessageIter *iter,
>> void *user_data)
>> {
>> GSupplicantInterface *interface;
>> const char *path = NULL;
>> + unsigned int properties_appended = GPOINTER_TO_UINT(user_data);
>>
>> SUPPLICANT_DBG("");
>>
>> @@ -2338,18 +2339,20 @@ static void interface_added(DBusMessageIter *iter,
>> void *user_data)
>> if (!interface)
>> return;
>>
>> + if (properties_appended == 0) {
>
> It is preferred to write this as !properties_appended
>
I was just trying to be exact with the types. I used unsigned int type
and value 0 for comparing because GUINT_TO_POINTER/GPOINTER_TO_UINT
functions use this type. But it's not a problem, I will use bool type
and ! operator. I will send shortly the v2 of the patch with this
changes.
Regards,
Jose Blanquicet
>> + supplicant_dbus_property_get_all(path,
>> + SUPPLICANT_INTERFACE
>> ".Interface",
>> + interface_property, interface,
>> + interface);
>> + return;
>> + }
>> +
>> dbus_message_iter_next(iter);
>> if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INVALID) {
>> supplicant_dbus_property_foreach(iter, interface_property,
>> interface);
>> interface_property(NULL, NULL, interface);
>> - return;
>> }
>> -
>> - supplicant_dbus_property_get_all(path,
>> - SUPPLICANT_INTERFACE ".Interface",
>> - interface_property, interface,
>> - interface);
>> }
>>
>> static void interface_removed(DBusMessageIter *iter, void *user_data)
>> @@ -2409,7 +2412,8 @@ static void service_property(const char *key,
>> DBusMessageIter *iter,
>> dbus_message_iter_get_basic(iter, &debug_showkeys);
>> SUPPLICANT_DBG("Debug show keys %u", debug_showkeys);
>> } else if (g_strcmp0(key, "Interfaces") == 0) {
>> - supplicant_dbus_array_foreach(iter, interface_added, NULL);
>> + supplicant_dbus_array_foreach(iter, interface_added,
>> + GUINT_TO_POINTER((unsigned
>> int) false));
>
> The original supplicant_dbus_array_foreach(iter, interface_added,
> NULL); works so it does not need changing.
>
>> } else if (g_strcmp0(key, "EapMethods") == 0) {
>> supplicant_dbus_array_foreach(iter, eap_method, NULL);
>> debug_strvalmap("EAP method", eap_method_map, eap_methods);
>> @@ -2479,7 +2483,7 @@ static void signal_interface_added(const char *path,
>> DBusMessageIter *iter)
>> SUPPLICANT_DBG("path %s %s", path, SUPPLICANT_PATH);
>>
>> if (g_strcmp0(path, SUPPLICANT_PATH) == 0)
>> - interface_added(iter, NULL);
>> + interface_added(iter, GUINT_TO_POINTER((unsigned int) true));
>
> A GUINT_TO_POINTER(true) seems to be enough here.
>
>> }
>>
>>
>> static void signal_interface_removed(const char *path, DBusMessageIter
>> *iter)
>
>
> Cheers,
>
> Patrik
>
------------------------------
Message: 4
Date: Wed, 13 Jul 2016 11:19:37 +0200
From: Jose Blanquicet <[email protected]>
To: [email protected]
Subject: [PATCH][v2] gsupplicant: Avoid skipping wpa_supplicant
interfaces
Message-ID: <[email protected]>
If the wpa_supplicant has been launched before ConnMan, when the Connman
calls the GetAll method on fi.w1.wpa_supplicant1, the properties are
returned as an array where there is an entry named "Interfaces". This
entry is an array itself with only the object path of the current
available interfaces. The problem occurs when ConnMan goes across this
array using the function interface_added(), because this function tries
also to extract the interface properties next to object path which is
wrong because properties are not appended in this message reply. So, by
doing dbus_message_iter_next(iter), we are actually skipping one interface
of the list and it will result in a future error because the skipped
interface(s) were not stored and ConnMan will not be aware of them.
This issue is due to the function interface_added() is also used when
signal "fi.w1.wpa_supplicant1.InterfaceAdded" arrives, and in this
message the properties are actually appended. This patch aims to solve
this issue by distinguishing the caller to avoid trying to extract
properties if they are not appended in the message.
---
gsupplicant/supplicant.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 09a3ac5..4cb533d 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2320,6 +2320,7 @@ static void interface_added(DBusMessageIter *iter, void
*user_data)
{
GSupplicantInterface *interface;
const char *path = NULL;
+ bool properties_appended = GPOINTER_TO_UINT(user_data);
SUPPLICANT_DBG("");
@@ -2338,18 +2339,20 @@ static void interface_added(DBusMessageIter *iter, void
*user_data)
if (!interface)
return;
+ if (!properties_appended) {
+ supplicant_dbus_property_get_all(path,
+ SUPPLICANT_INTERFACE
".Interface",
+ interface_property, interface,
+ interface);
+ return;
+ }
+
dbus_message_iter_next(iter);
if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INVALID) {
supplicant_dbus_property_foreach(iter, interface_property,
interface);
interface_property(NULL, NULL, interface);
- return;
}
-
- supplicant_dbus_property_get_all(path,
- SUPPLICANT_INTERFACE ".Interface",
- interface_property, interface,
- interface);
}
static void interface_removed(DBusMessageIter *iter, void *user_data)
@@ -2479,7 +2482,7 @@ static void signal_interface_added(const char *path,
DBusMessageIter *iter)
SUPPLICANT_DBG("path %s %s", path, SUPPLICANT_PATH);
if (g_strcmp0(path, SUPPLICANT_PATH) == 0)
- interface_added(iter, NULL);
+ interface_added(iter, GUINT_TO_POINTER(true));
}
static void signal_interface_removed(const char *path, DBusMessageIter *iter)
--
1.9.1
------------------------------
Message: 5
Date: Wed, 13 Jul 2016 13:20:49 +0300
From: Patrik Flykt <[email protected]>
To: Philip Withnall <[email protected]>,
[email protected]
Subject: Re: [PATCH] connman.service: Use ProtectSystem=true to allow
writing /etc/localtime
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Mon, 2016-07-11 at 18:27 +0100, Philip Withnall wrote:
> Setting the timezone requires unlinking and relinking /etc/localtime,
> so we need /etc to be mounted read?write. This means that commit
> dc8f151e has to be softened to ProtectSystem=true rather than
> ProtectSystem=full. This mounts most of the filesystem as read-only,
> apart from /etc, which is read?write.
>
> Signed-off-by: Philip Withnall <[email protected]>
> ---
> ?src/connman.service.in | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/connman.service.in b/src/connman.service.in
> index 57eaaf9..d5d6d44 100644
> --- a/src/connman.service.in
> +++ b/src/connman.service.in
> @@ -15,7 +15,7 @@ ExecStart=@sbindir@/connmand -n
> ?StandardOutput=null
> ?CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
> CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE
> ?ProtectHome=true
> -ProtectSystem=full
> +ProtectSystem=true
> ?
> ?[Install]
> ?WantedBy=multi-user.target
> --?
> 2.5.5
Yes, this will fix the problem. On the other hand there is also a
desired use case that ConnMan has write access only to as few places as
possible, for run-time information that would be /var/run/connman. In
order to keep in line with that, I suggest something similar that was
done for resolv.conf handling. See a few commits
from?3a9ad49c8c8448875375a67913af98f74bca0ad7 forwards.
So this could be handled by copying the symlink/file from
/etc/localtime to /var/run with tmpfiles.d and create the link to /etc
(see e.g. scripts/connman_resolvconf.conf.in).
What do you think?
Patrik
------------------------------
Message: 6
Date: Wed, 13 Jul 2016 14:25:02 +0300
From: Patrik Flykt <[email protected]>
To: Feng Wang <[email protected]>, [email protected]
Subject: Re: [PATCH] dhcpv6: use correct dhcp renew time when valid
life-time is infinity.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Tue, 2016-06-28 at 14:34 -0700, Feng Wang wrote:
> Based on RFC 3315, 22.6, the valid life-time is infinite when its
> value is 0xffffffff. In the g_dhcpv6_client_get_timeouts, the expire
> data type is time_t. If time_t is uint32, the last_request time plus
> 0xffffffff will wrapover so that expire time is smaller than current
> time. Thus the dhcpv6 will restart immediately(dhcpv6_restart called).
> ---
> ?gdhcp/client.c | 9 +++++++--
> ?src/dhcpv6.c???| 6 +++++-
> ?2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/gdhcp/client.c b/gdhcp/client.c
> index 9012b38..2be3982 100644
> --- a/gdhcp/client.c
> +++ b/gdhcp/client.c
> @@ -835,8 +835,13 @@ int g_dhcpv6_client_get_timeouts(GDHCPClient
> *dhcp_client,
> ? if (started)
> ? *started = dhcp_client->last_request;
> ?
> - if (expire)
> - *expire = dhcp_client->last_request + dhcp_client->expire;
> + if (expire) {
> + if (dhcp_client->expire == 0xffffffff)
> + /* RFC3315 22.6 infinite valid-lifetime */
> + *expire = 0xffffffff;
> + else
> + *expire = dhcp_client->last_request +
> dhcp_client->expire;
> + }
Coming back to this, RFC 3315, Section 22.5, indicates that "...If the
"shortest" preferred lifetime is 0xffffffff ("infinity"), the
recommended T1 and T2 values are also 0xffffffff..."
So this all could be made a bit easier by always setting T1, T2 and
expire to 0xffffffff when dhcp->expire is 0xffffffff.
And this would be patch #2.?
> ? return 0;
> ?}
> diff --git a/src/dhcpv6.c b/src/dhcpv6.c
> index 9e21040..cd5733a 100644
> --- a/src/dhcpv6.c
> +++ b/src/dhcpv6.c
> @@ -1195,7 +1195,7 @@ static int check_restart(struct connman_dhcpv6 *dhcp)
> ? NULL, &expired);
> ? current = time(NULL);
> ?
> - if (current >= expired) {
> + if (current >= expired && expired != 0xffffffff) {
> ? DBG("expired by %d secs", (int)(current - expired));
> ?
> ? g_timeout_add(0, dhcpv6_restart, dhcp);
> @@ -1442,6 +1442,10 @@ int __connman_dhcpv6_start_renew(struct
> connman_network *network,
> ? /* RFC 3315, 22.4
> ? ?* Client can choose the timeout.
> ? ?*/
> + if (expired == 0xffffffff) {
> + ????/* RFC 3315, 22.6 infinite valid-lifetime */
> + ????return 0;
> + }
> ? T1 = (expired - started) / 2;
> ? T2 = (expired - started) / 10 * 8;
> ? }
All instances where T1 and T2 are handled should be checked for
"infinity" as RFC 3315, Section 22.4 also says that "...a client will
never attempt to extend the lifetimes of any addresses in an IA with T1
set to 0xffffffff.??A client will never attempt to use a Rebind message
to locate a different server to extend the lifetimes of any addresses
in an IA with T2 set to 0xffffffff...". To get to this behavior, all
usage of T1 and T2 should be checked.
This would be then patch #1.
Cheers,
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 9, Issue 5
*************************************
