Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe 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] clock: Add TimeSynced signal emitted when the system time has
been synced
(Daniel Wagner)
2. Re: [PATCH] clock: Add functions to trigger time synchronization via the
clock API
(Daniel Wagner)
3. Re: [PATCH] services: Escape passphrase string (Daniel Wagner)
4. Re: [PATCH] timeserver: Split new service and configuration update
(Daniel Wagner)
5. Unreliable 4G LTE interface IP address (Jupiter)
----------------------------------------------------------------------
Date: Mon, 28 Dec 2020 20:52:37 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] clock: Add TimeSynced signal emitted when the
system time has been synced
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
Could you please send your patches directly and not as attachment? I
have to copy the patch over to for the review. The simplest way is to
use 'git send-email' directly.
On Wed, Dec 23, 2020 at 03:19:30PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> As our system depends on https requests, and for boot performance
> purposes, we need to be informed when a time synchronization (via the
> ntp) is performed.
>
> In this aim, please find the attached patch, adding the TimeSynced
> signal emitted when the system time has been synced.
> From cf311e998c85b18703886b49bc98c06840612c22 Mon Sep 17 00:00:00 2001
> From: Emmanuel VAUTRIN <[email protected]>
> Date: Wed, 23 Dec 2020 12:06:04 +0100
> Subject: [PATCH] clock: Add TimeSynced signal emitted when the system time has
> been synced.
>
>
Please add a commit message explaining what problem it solves.
> ---
> doc/clock-api.txt | 4 ++++
> include/dbus.h | 2 ++
> src/clock.c | 2 ++
> src/dbus.c | 30 ++++++++++++++++++++++++++++++
> src/timeserver.c | 3 +++
> 5 files changed, 41 insertions(+)
>
> diff --git a/doc/clock-api.txt b/doc/clock-api.txt
> index 6818f5a8..2e368d0a 100644
> --- a/doc/clock-api.txt
> +++ b/doc/clock-api.txt
> @@ -27,6 +27,10 @@ Signals PropertyChanged(string name, variant
> value) [experimental]
> This signal indicates a changed value of the given
> property.
>
> + TimeSynced(uint64 Time) [experimental]
> +
> + This signal indicates that the current system time
> + has been synced.
I think it would make more sense to just emit a bool and send out the
Time event along side. In this case it would be the same event for auto
or manual mode. This would be more consistent in my opinion.
Also, TimeserverSynced would be also be better name for it in this case.
> Properties uint64 Time [readonly or readwrite] [experimental]
>
> diff --git a/include/dbus.h b/include/dbus.h
> index bcab4189..3208adc5 100644
> --- a/include/dbus.h
> +++ b/include/dbus.h
> @@ -85,6 +85,8 @@ dbus_bool_t connman_dbus_setting_changed_array(const char
> *owner,
> const char *path, const char *key, int type,
> connman_dbus_append_cb_t function,
> void *user_data);
> +dbus_bool_t connman_dbus_time_synced(const char *path,
> + const char *interface);
>
> static inline void connman_dbus_dict_open(DBusMessageIter *iter,
> DBusMessageIter *dict)
> diff --git a/src/clock.c b/src/clock.c
> index 0fde2c34..315e908e 100644
> --- a/src/clock.c
> +++ b/src/clock.c
> @@ -381,6 +381,8 @@ static const GDBusMethodTable clock_methods[] = {
> static const GDBusSignalTable clock_signals[] = {
> { GDBUS_SIGNAL("PropertyChanged",
> GDBUS_ARGS({ "name", "s" }, { "value", "v" })) },
> + { GDBUS_SIGNAL("TimeSynced",
> + GDBUS_ARGS({ "name", "s" }, { "value", "v" })) },
> { },
> };
>
> diff --git a/src/dbus.c b/src/dbus.c
> index d80a46ce..73d1bad6 100644
> --- a/src/dbus.c
> +++ b/src/dbus.c
> @@ -23,6 +23,8 @@
> #include <config.h>
> #endif
>
> +#include <sys/time.h>
> +
> #include <string.h>
> #include <errno.h>
> #include <gdbus.h>
> @@ -382,6 +384,34 @@ dbus_bool_t connman_dbus_setting_changed_array(const
> char *owner,
> return TRUE;
> }
>
> +dbus_bool_t connman_dbus_time_synced(const char *path, const char *interface)
> +{
> + DBusMessage *signal;
> + DBusMessageIter iter;
> + struct timeval tv;
> + dbus_uint64_t val = 0;
> +
> + if (!path)
> + return FALSE;
> +
> + signal = dbus_message_new_signal(path, interface, "TimeSynced");
> + if (!signal)
> + return FALSE;
> +
> + dbus_message_iter_init_append(signal, &iter);
> +
> + if (gettimeofday(&tv, NULL) == 0) {
> + val = tv.tv_sec;
> + }
> +
> + connman_dbus_property_append_basic(&iter, "Time",
> + DBUS_TYPE_UINT64, &val);
> +
> + g_dbus_send_message(connection, signal);
> +
> + return TRUE;
> +}
> +
> dbus_bool_t __connman_dbus_append_objpath_dict_array(DBusMessage *msg,
> connman_dbus_append_cb_t function, void *user_data)
> {
> diff --git a/src/timeserver.c b/src/timeserver.c
> index decca153..ebd1fab3 100644
> --- a/src/timeserver.c
> +++ b/src/timeserver.c
> @@ -57,6 +57,9 @@ static void ntp_callback(bool success, void *user_data)
>
> if (!success)
> sync_next();
> + else
> + connman_dbus_time_synced(CONNMAN_MANAGER_PATH,
> + CONNMAN_CLOCK_INTERFACE);
You should also add it to get_properties.
Daniel
------------------------------
Date: Mon, 28 Dec 2020 20:57:31 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] clock: Add functions to trigger time
synchronization via the clock API
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Wed, Dec 23, 2020 at 04:14:52PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> As our system is based on mandatory https requests, in some degraded
> cases, we need to trigger a time synchronization. For example, when
> booting with the clock TimeUpdates equal to manual, changing it to
> auto does not suffy to update the system time.
Instead adding a API as workaround, why not fixing the problem you
describe? When changing from manual to auto, try to sync?
> Please find the attached patch, adding a clock API providing a way to
> trigger a time synchronization.
I don't like this at all. This is a really ad-hock API for something we
just need to fix internally.
Daniel
------------------------------
Date: Mon, 28 Dec 2020 20:59:20 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] services: Escape passphrase string
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Wed, Dec 23, 2020 at 04:04:42PM +0100, Daniel Wagner wrote:
> The WiFi passphrase might use chars which need escaping because
> g_key_file_get_string() is trying to decode the strings it reads.
Patch applied.
------------------------------
Date: Mon, 28 Dec 2020 20:59:40 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] timeserver: Split new service and configuration
update
To: [email protected]
Cc: VAUTRIN Emmanuel <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Wed, Dec 23, 2020 at 01:18:55PM +0100, Daniel Wagner wrote:
> Allow to update the existing used service with a new time server
> configuration. Instead overloading the __connman_timeservice_sync()
> function introduce a new function for updating the currently used
> service for time synchronization. By this we document clearly in the
> code what is supposed to be updated.
Patch applied.
------------------------------
Date: Tue, 29 Dec 2020 18:50:49 +1100
From: Jupiter <[email protected]>
Subject: Unreliable 4G LTE interface IP address
To: connman <[email protected]>
Message-ID:
<CAA=hcWTw4ZvGL=YZvpbcZ+qsR4Y8gKvbiMWEfPNJwzkzTe=h...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
I am running 4G LTE managed by ofono version 1.30 and connman version
1.37, it works well most of the time, but occasionally, the 4G modem
is connected, there is no IP address so I have to run systemctl
restart connman to bring the IP address back. As it is intermittent
and random, it is hard to debug, any insight advice what I could be
missing, why couldn't connman pick up the 4G LTE IP reliably?
Thank you.
Kind regards,
Jupiter
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 62, Issue 31
***************************************
