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. [PATCH v1 4/5] timeserver: Retry NTP servers periodically on
startup (Daniel Wagner)
2. [PATCH v1 5/5] ntp: Report EPERM to timeserver (Daniel Wagner)
3. Re: [PATCH 0/3] Fixes and extensions for WPS support
(Jose Blanquicet)
4. Re: ipv6 redefinition build issue with 4.15-rc8 (Daniel Wagner)
5. Re: [PATCH 0/3] Fixes and extensions for WPS support
(Daniel Wagner)
6. Re: [PATCH 0/3] Fixes and extensions for WPS support
(Robert Tiemann)
7. Re: ipv6 redefinition build issue with 4.15-rc8 (Jonas Bonn)
8. Re: ipv6 redefinition build issue with 4.15-rc8 (Neil MacLeod)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Jan 2018 08:50:31 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH v1 4/5] timeserver: Retry NTP servers periodically on
startup
Message-ID: <[email protected]>
When ConnMan starts up and we haven't connected to a timeserver, the
current algorithm will try all server once in the timer server list
and then stops. There is a recheck interval (7200 seconds) but that is
far too long if we no server has been selected so far. So we don't
find any server at startup we just retry in 5 seconds again.
The back off timeout is set hard to 5 seconds which could made into an
exponential value, though for a starting point let's try if this cures
the problem reported with Raspberry Pi boards which lacks a battery
buffered RTC.
Fixes CM-636
---
src/timeserver.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 72 insertions(+), 12 deletions(-)
diff --git a/src/timeserver.c b/src/timeserver.c
index 68d443494abf..55ec961e38ac 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -34,9 +34,11 @@
#define TS_RECHECK_INTERVAL 7200
+static GSList *timeservers_list = NULL;
static GSList *ts_list = NULL;
static char *ts_current = NULL;
static int ts_recheck_id = 0;
+static int ts_backoff_id = 0;
static GResolv *resolv = NULL;
static int resolv_id = 0;
@@ -125,11 +127,57 @@ static void resolv_result(GResolvResultStatus status,
char **results,
}
/*
- * Once the timeserver list (ts_list) is created, we start querying the
- * servers one by one. If resolving fails on one of them, we move to the
- * next one. The user can enter either an IP address or a URL for the
- * timeserver. We only resolve the URLs. Once we have an IP for the NTP
- * server, we start querying it for time corrections.
+ * Once the timeserver list (timeserver_list) is created, we start
+ * querying the servers one by one. If resolving fails on one of them,
+ * we move to the next one. The user can enter either an IP address or
+ * a URL for the timeserver. We only resolve the URLs. Once we have an
+ * IP for the NTP server, we start querying it for time corrections.
+ */
+static void timeserver_sync_start(void)
+{
+ GSList *list;
+
+ for (list = timeservers_list; list; list = list->next) {
+ char *timeserver = list->data;
+
+ ts_list = g_slist_prepend(ts_list, g_strdup(timeserver));
+ }
+ ts_list = g_slist_reverse(ts_list);
+
+ ts_current = ts_list->data;
+
+ ts_list = g_slist_delete_link(ts_list, ts_list);
+
+ /* if it's an IP, directly query it. */
+ if (connman_inet_check_ipaddress(ts_current) > 0) {
+ DBG("Using timeserver %s", ts_current);
+
+ __connman_ntp_start(ts_current, ntp_callback, NULL);
+
+ return;
+ }
+
+ DBG("Resolving timeserver %s", ts_current);
+
+ resolv_id = g_resolv_lookup_hostname(resolv, ts_current,
+ resolv_result, NULL);
+
+ return;
+}
+
+static gboolean timeserver_sync_restart(gpointer user_data)
+{
+ timeserver_sync_start();
+ ts_backoff_id = 0;
+
+ return FALSE;
+}
+
+/*
+ * Select the next time server from the working list (ts_list) because
+ * for some reason the first time server in the list didn't work. If
+ * none of the server did work we start over with the first server
+ * with a backoff.
*/
static void sync_next()
{
@@ -141,8 +189,13 @@ static void sync_next()
__connman_ntp_stop();
/* Get the 1st server in the list */
- if (!ts_list)
+ if (!ts_list) {
+ DBG("No timeserver could be used, restart probing in 5
seconds");
+
+ ts_backoff_id = g_timeout_add_seconds(5,
+ timeserver_sync_restart, NULL);
return;
+ }
ts_current = ts_list->data;
@@ -280,6 +333,11 @@ static void ts_recheck_disable(void)
g_source_remove(ts_recheck_id);
ts_recheck_id = 0;
+ if (ts_backoff_id) {
+ g_source_remove(ts_backoff_id);
+ ts_backoff_id = 0;
+ }
+
if (ts_current) {
g_free(ts_current);
ts_current = NULL;
@@ -338,20 +396,20 @@ int __connman_timeserver_sync(struct connman_service
*default_service)
g_strfreev(nameservers);
- g_slist_free_full(ts_list, g_free);
+ g_slist_free_full(timeservers_list, g_free);
- ts_list = __connman_timeserver_get_all(service);
+ timeservers_list = __connman_timeserver_get_all(service);
- __connman_service_timeserver_changed(service, ts_list);
+ __connman_service_timeserver_changed(service, timeservers_list);
- if (!ts_list) {
+ if (!timeservers_list) {
DBG("No timeservers set.");
return 0;
}
ts_recheck_enable();
- sync_next();
+ timeserver_sync_start();
return 0;
}
@@ -407,8 +465,10 @@ static void timeserver_stop(void)
resolv = NULL;
}
- g_slist_free_full(ts_list, g_free);
+ g_slist_free_full(timeservers_list, g_free);
+ timeservers_list = NULL;
+ g_slist_free_full(ts_list, g_free);
ts_list = NULL;
__connman_ntp_stop();
--
2.14.3
------------------------------
Message: 2
Date: Wed, 17 Jan 2018 08:50:32 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH v1 5/5] ntp: Report EPERM to timeserver
Message-ID: <[email protected]>
If an iptables rule is installed like
iptables -A OUTPUT -p udp --dport 123 -j DROP
we will get an EPERM. Report this so that the timeserver retry state
machine is able to deal with this.
---
src/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ntp.c b/src/ntp.c
index c0f1d3d45c4a..d2d8e4af5be6 100644
--- a/src/ntp.c
+++ b/src/ntp.c
@@ -212,7 +212,7 @@ static void send_packet(struct ntp_data *nd, struct
sockaddr *server,
inet_ntop(server->sa_family, addr, ipaddrstring,
sizeof(ipaddrstring)),
errno, strerror(errno));
- if (errno == ENETUNREACH)
+ if (errno == ENETUNREACH || errno == EPERM)
nd->cb(false, nd->user_data);
return;
--
2.14.3
------------------------------
Message: 3
Date: Wed, 17 Jan 2018 08:54:23 +0100
From: Jose Blanquicet <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: [email protected], Daniel Wagner <[email protected]>
Subject: Re: [PATCH 0/3] Fixes and extensions for WPS support
Message-ID:
<CAFC8iJJ+a0t00=evi7=dNRoRTeR7Qxxnx7kwWyL+b-B=+b9...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Robert, Daniel,
If we will go ahead, I think that maybe it's worth to generate a
PropertyChanged signal to notify Security property has changed when
wps_adversing is added/removed. Currently PropertyChanged signal on
Security is not generated because when security changes, e.g. PSK ->
OPEN, we consider it as a new service. But with wps_advertising it is
not the case, so I think that signal should be generated. That would
ease job for a ConnMan client. What do you think?
Furthermore, Service API documentation should be updated with the new
possible value for Security property.
Thanks,
Jose Blanquicet
On Mon, Jan 15, 2018 at 10:28 AM, Robert Tiemann <[email protected]> wrote:
>
>
> On 01/15/2018 12:42 AM, Jose Blanquicet wrote:
>> I would just suggest, as usual, to check the patch with checkpatch.pl
>> for style errors like "line over 80 characters" and others. We use
>> Linux kernel coding style.
>
> OK, I've sent another patch series. There is still one warning for the
> the third patch about the comment style in plugins/wifi.c.
------------------------------
Message: 4
Date: Wed, 17 Jan 2018 08:59:40 +0100
From: Daniel Wagner <[email protected]>
To: Neil MacLeod <[email protected]>, Hauke Mehrtens
<[email protected]>
Cc: [email protected], "[email protected]"
<[email protected]>, "David S. Miller"
<[email protected]>
Subject: Re: ipv6 redefinition build issue with 4.15-rc8
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Neil,
On 01/16/2018 07:51 PM, Neil MacLeod wrote:
> Since this commit in 4.15-rc8:
>
> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd
>
> building connman 1.35 with glibc 2.26 now fails as follows:
>
> http://ix.io/EbP
>
> I'm not sure if this is a kernel issue, a glibc issue, or a connman issue.
>
> Reverting the kernel commit resolves the issue, but isn't ideal (unless
> it's the correct solution, of course).
>
> Does anyone have any better ideas?
Since ConnMan does not redefine 'struct in6_addr' and friends I would
say it is kernel/glibc header include problem. But I might be wrong here.
@Hauke: Do you happen to know what is going on?
Thanks,
Daniel
------------------------------
Message: 5
Date: Wed, 17 Jan 2018 09:03:04 +0100
From: Daniel Wagner <[email protected]>
To: Jose Blanquicet <[email protected]>, Robert Tiemann
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/3] Fixes and extensions for WPS support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jose,
On 01/17/2018 08:54 AM, Jose Blanquicet wrote:
> Hi Robert, Daniel,
>
> If we will go ahead, I think that maybe it's worth to generate a
> PropertyChanged signal to notify Security property has changed when
> wps_adversing is added/removed. Currently PropertyChanged signal on
> Security is not generated because when security changes, e.g. PSK ->
> OPEN, we consider it as a new service. But with wps_advertising it is
> not the case, so I think that signal should be generated. That would
> ease job for a ConnMan client. What do you think?
Sounds reasonable to me.
> Furthermore, Service API documentation should be updated with the new
> possible value for Security property.
Yep, good plan.
Any objection to Robert's v2? Apart of the comment thingy it looks ready
to be merged.
Thanks,
Daniel
------------------------------
Message: 6
Date: Wed, 17 Jan 2018 09:27:16 +0100
From: Robert Tiemann <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected], Daniel Wagner <[email protected]>
Subject: Re: [PATCH 0/3] Fixes and extensions for WPS support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 01/17/2018 08:54 AM, Jose Blanquicet wrote:
> Hi Robert, Daniel,
Hi!
> If we will go ahead, I think that maybe it's worth to generate a
> PropertyChanged signal to notify Security property has changed when
> wps_adversing is added/removed.
This would be helpful indeed. My current client code constantly scans
for WLANs and reads out all data of all services on _any_ change
reported. Not very efficient, but it turned out to be the most
reliable way to keep up with changes.
Alternatively, wps_advertising could be turned into a property in its
own right, outside of Security in case Security is not supposed to
change. I just thought it would make sense to put it into Security.
> Furthermore, Service API documentation should be updated with the new
> possible value for Security property.
Yes.
I guess to generate the PropertyChanged signal, a function similar to
strength_changed() would be needed which calls
connman_dbus_property_changed_array(), right?
Shall I prepare two patches (one for the signal, one for the docs)?
Robert
------------------------------
Message: 7
Date: Wed, 17 Jan 2018 10:03:02 +0100
From: Jonas Bonn <[email protected]>
To: Daniel Wagner <[email protected]>, Neil MacLeod <[email protected]>,
Hauke Mehrtens <[email protected]>
Cc: [email protected], "[email protected]"
<[email protected]>, "David S. Miller"
<[email protected]>
Subject: Re: ipv6 redefinition build issue with 4.15-rc8
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 01/17/2018 08:59 AM, Daniel Wagner wrote:
> Hi Neil,
>
> On 01/16/2018 07:51 PM, Neil MacLeod wrote:
>> Since this commit in 4.15-rc8:
>>
>> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd
>>
>>
>>
>> building connman 1.35 with glibc 2.26 now fails as follows:
>>
>> http://ix.io/EbP
>>
>> I'm not sure if this is a kernel issue, a glibc issue, or a connman
>> issue.
>>
>> Reverting the kernel commit resolves the issue, but isn't ideal
>> (unless it's the correct solution, of course).
>>
>> Does anyone have any better ideas?
Try switching the order of these headers around (src/tethering.c)...
netinet/in.h seems to depend on linux/in.h being included _first_ and
it's presumably being pulled in via linux/if_bridge.h now as a result of
the kernel patch (couldn't immediately see why, though... I suspect the
inclusion of libc-compat.h is the culprit.)
#include <netinet/in.h>
#include <linux/if_bridge.h>
Yes, this is a hack and only masks the issue... nonetheless.
/Jonas
>
> Since ConnMan does not redefine 'struct in6_addr' and friends I would
> say it is kernel/glibc header include problem. But I might be wrong here.
>
> @Hauke: Do you happen to know what is going on?
>
> Thanks,
> Daniel
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
------------------------------
Message: 8
Date: Wed, 17 Jan 2018 15:25:34 +0000
From: Neil MacLeod <[email protected]>
To: Jonas Bonn <[email protected]>
Cc: Daniel Wagner <[email protected]>, Hauke Mehrtens <[email protected]>,
[email protected], "[email protected]"
<[email protected]>, "David S. Miller"
<[email protected]>
Subject: Re: ipv6 redefinition build issue with 4.15-rc8
Message-ID:
<cafbqk8mtytgliviabqvk_ht+ymr2vcnzux_5+c8gn36icec...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
All
Many thanks for the replies.
To ensure my build environment is sane I tested again without reverting the
kernel commit, and reproduced the connman build failure.
Next I tested the change suggested by Hauke (kernel patch: http://ix.io/Eh5)
and connman fails to build, however it fails with a different error this
time: http://ix.io/Eh2
I then tested the change suggested by Jonas (connman patch: http://ix.io/Eh6)
and connman builds successfully, no failure, so this might be a potential
fix.
I'll now try a clean build with Jonas' patch and see if any other packages
fail to build for the same reason as connman (I'm building a complete
embedded distro with about 700 packages).
I'll post again later with an update.
Thanks
Neil
On 17 January 2018 at 09:03, Jonas Bonn <[email protected]> wrote:
> On 01/17/2018 08:59 AM, Daniel Wagner wrote:
>
>> Hi Neil,
>>
>> On 01/16/2018 07:51 PM, Neil MacLeod wrote:
>>
>>> Since this commit in 4.15-rc8:
>>>
>>> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27
>>> e4e155efa760aa01551fd
>>>
>>> building connman 1.35 with glibc 2.26 now fails as follows:
>>>
>>> http://ix.io/EbP
>>>
>>> I'm not sure if this is a kernel issue, a glibc issue, or a connman
>>> issue.
>>>
>>> Reverting the kernel commit resolves the issue, but isn't ideal (unless
>>> it's the correct solution, of course).
>>>
>>> Does anyone have any better ideas?
>>>
>>
> Try switching the order of these headers around (src/tethering.c)...
> netinet/in.h seems to depend on linux/in.h being included _first_ and it's
> presumably being pulled in via linux/if_bridge.h now as a result of the
> kernel patch (couldn't immediately see why, though... I suspect the
> inclusion of libc-compat.h is the culprit.)
>
> #include <netinet/in.h>
> #include <linux/if_bridge.h>
>
> Yes, this is a hack and only masks the issue... nonetheless.
>
> /Jonas
>
>
>
>> Since ConnMan does not redefine 'struct in6_addr' and friends I would say
>> it is kernel/glibc header include problem. But I might be wrong here.
>>
>> @Hauke: Do you happen to know what is going on?
>>
>> Thanks,
>> Daniel
>> _______________________________________________
>> 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/20180117/484373bc/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 27, Issue 13
***************************************
