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] doc: Fixed typo mistakes (Nishant Chaprana)
2. Re: [PATCH 1/2] ntp: Add option TimeUpdateThreshold
(Boszormenyi Zoltan)
3. Re: [PATCH 0/2] Extend NTP for exotic use cases
(Boszormenyi Zoltan)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Mar 2016 10:42:42 +0530
From: Nishant Chaprana <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: [PATCH] doc: Fixed typo mistakes
Message-ID: <[email protected]>
---
doc/agent-api.txt | 2 +-
doc/config-format.txt | 2 +-
doc/connmanctl.1.in | 2 +-
doc/counter-api.txt | 4 ++--
doc/plugin-api.txt | 6 +++---
doc/service-api.txt | 2 +-
doc/session-api.txt | 2 +-
doc/vpn-overview.txt | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/agent-api.txt b/doc/agent-api.txt
index aa7271d..d357169 100644
--- a/doc/agent-api.txt
+++ b/doc/agent-api.txt
@@ -119,7 +119,7 @@ Fields string Name
string PreviousPassphrase
The previous passphrase successfully saved, i.e.
- which led to a successfull connection. This field is
+ which led to a successful connection. This field is
provided as an informational argument when connecting
with it does not work anymore, for instance when it
has been changed on the AP. Such argument appears when
diff --git a/doc/config-format.txt b/doc/config-format.txt
index eae51e0..e7089af 100644
--- a/doc/config-format.txt
+++ b/doc/config-format.txt
@@ -51,7 +51,7 @@ Allowed fields:
Example: 2001:db8::2/64/2001:db8::1
2001:db8::1:2:3:4/64
- IPv6.Privacy: IPv6 privacy option. Value can be either "disabled",
- "enabled" or "preferred" (or the misspelled "prefered"). See use_tempaddr
+ "enabled" or "preferred" (or the misspelled "preferred"). See use_tempaddr
variable description in Linux kernel Documentation/networking/ip-sysctl.txt
file.
- MAC: MAC address of the interface where this setting should be applied.
diff --git a/doc/connmanctl.1.in b/doc/connmanctl.1.in
index 0f891bd..ad2a01d 100644
--- a/doc/connmanctl.1.in
+++ b/doc/connmanctl.1.in
@@ -47,7 +47,7 @@ Shows the abbreviated help menu in the terminal.
.PP
.TP
.B state
-Shows the system properties. Includes ths online state of the
+Shows the system properties. Includes this online state of the
system, offline mode, and session mode.
.PP
.TP
diff --git a/doc/counter-api.txt b/doc/counter-api.txt
index 32411d5..c0d9b76 100644
--- a/doc/counter-api.txt
+++ b/doc/counter-api.txt
@@ -47,12 +47,12 @@ Methods void Release()
RX.Errors
- Total number of erronous packets
+ Total number of erroneous packets
received.
TX.Errors
- Total number of erronous packets
+ Total number of erroneous packets
sent.
RX.Dropped
diff --git a/doc/plugin-api.txt b/doc/plugin-api.txt
index 616938b..3ed8f2a 100644
--- a/doc/plugin-api.txt
+++ b/doc/plugin-api.txt
@@ -65,7 +65,7 @@ plugin initialization function, bluetooth_init() in this
example:
connman_technology_driver_register(&tech_driver);
-In this document the error check is supressed for the sake of simplicity.
+In this document the error check is suppressed for the sake of simplicity.
All plugins should check return values in driver registration functions.
After this call ConnMan becomes aware of the new Technology plugin and will
@@ -101,7 +101,7 @@ And to register the driver:
'connman_device_driver_register()' is called during the plugin initialization
process, not necessarily at the plugin init function.
-In this document the error check is supressed for the sake of simplicity.
+In this document the error check is suppressed for the sake of simplicity.
All plugins should check return values in driver registration functions.
Additionally code to handle the detection of new devices needs to be written
@@ -147,7 +147,7 @@ And then call the register function:
connman_network_driver_register(&network_driver);
-In this document the error check is supressed for the sake of simplicity.
+In this document the error check is suppressed for the sake of simplicity.
All plugins should check return values in driver registration functions.
The next step would be the probe of a Network entity, for the bluetooth
diff --git a/doc/service-api.txt b/doc/service-api.txt
index e2e9e84..763414e 100644
--- a/doc/service-api.txt
+++ b/doc/service-api.txt
@@ -378,7 +378,7 @@ Properties string State [readonly]
enabled and system prefers to use public
addresses over temporary addresses.
- Value "prefered" means that privacy extension is
+ Value "preferred" means that privacy extension
is
enabled and system prefers temporary addresses
over public addresses.
diff --git a/doc/session-api.txt b/doc/session-api.txt
index 3aac535..9e588a9 100644
--- a/doc/session-api.txt
+++ b/doc/session-api.txt
@@ -140,7 +140,7 @@ Settings string State [readonly]
The services are sorted in the order of the bearer
entries in this list.
- Also "*" matches any bearer. This is usefull to prefer
+ Also "*" matches any bearer. This is useful to prefer
certain bearers such as 'wifi' with a fallback to any
other available bearer.
diff --git a/doc/vpn-overview.txt b/doc/vpn-overview.txt
index 42b6e94..d7be919 100644
--- a/doc/vpn-overview.txt
+++ b/doc/vpn-overview.txt
@@ -54,7 +54,7 @@ is established (meaning VPN client has managed to create a
connection
to VPN server), then State property is set to "ready" and PropertyChanged
signal is sent. If the connection cannot be established, then
State property is set to "failure".
-After successfull connection, the relevant connection properties are sent
+After successful connection, the relevant connection properties are sent
by PropertyChanged signal; like IPv[4|6] information, the index of the
VPN tunneling interface (if there is any), nameserver information,
server specified routes etc.
--
1.9.1
------------------------------
Message: 2
Date: Thu, 10 Mar 2016 09:50:25 +0100
From: Boszormenyi Zoltan <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 1/2] ntp: Add option TimeUpdateThreshold
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
2016-03-08 12:36 keltez?ssel, Patrik Flykt ?rta:
> On Tue, 2016-03-08 at 10:11 +0100, [email protected] wrote:
>> Hi,
>>
>>> I don't think such a short interval was the intention here. I myself was
>>> in the belief that it was 2 seconds. Need to have a look at related
>>> patches to see if it has broken at some point.
>>>
>>> I'm not a very big fan of adding more configuration variables if finding
>>> a reasonable value fixes the case.
>> I don't think you can find a value that satisfies anyone.
> What is the delta you're seeing here? In the log you can find something
> like 'ntp: time slew +0.007760 s', and running with '-d src/ntp.c' gives
> even more details.
Most of the time the delta is small in the range of 0.04 - 0.9 s but
sometimes it is in the range of 0.15-0.17 seconds.
> You said RTC in your question, but you actually meant system time?
Yes, sorry.
> If
> the system clock jumps that much, there is a pretty good chance
> something else has been going wrong as well.
I saw in the code that Connman conforms to the reply from the NTP
server for the time of the next query. Maybe this causes the larger delta
when the timeserver tells the client to use a particularly large query interval.
This may be the reason the original NTPD has a setting for the minimum
and maximum query time. This is what I have confused with the threshold
to decide between settimeofday vs adjtime. Reading the ntpd manual
and observing its behaviour shows that if the time delta grows too big
it simply quits. With "ntpd -x", the time delta can be up to 10 minutes,
otherwise it's way smaller.
Another source of the problem may be the unconditional usage of
the gateway address as a timeserver. You know, if you have a watch,
you know the exact time. Having more than one, you don't. This is the
case with using more than one timeservers that may operate on slightly
different times.
> If the round trip time in
> the network is large, then the time computed will fall out of this range
> and the system clock be set to its computed value. Notice also that
> ConnMan only sets system time, it does not touch any hw RTCs.
>
> Adjusting the clock does not make much sense if the delta starts to be a
> few seconds. With the clock for example 4 seconds off and a max
> adjustment of 0.5 ms/s, the whole adjustment procedure will take a bit
> more than 2 hours. This again starts to be about the maximum that can be
> "reasonably" tolerated on a system. For example systemd-networkd uses
> +/- 0.4 seconds, ntpd uses also 128 ms when deciding whether to adjust
> the rate of the clock or set it.
>
>> I would personally set it to 30 seconds, but e.g. one of my bosses
>> demanded to set it to a year to NEVER use settimeofday, to mimic
>> the ntpdate/ntpd split behaviour.
> See the TimeUpdates property of the Clock API, doc/clock-api.txt to
> disable this.
With TimeUpdates=manual, the NTP client is disabled in Connman.
I would like to have another setting (like TimeUpdates=mimic-ntpd)
or the "auto" behaviour modified like this:
1. At start, use settimeofday unconditionally.
2. Every other time use adjtime, unless the time difference grows too large.
Otherwise use settimeofday again. I still think the value of "too large"
needs to be configurable.
3. Have the option to maximize the next poll time.
> With that it can be left as some other application's
> problem to deal with the system clock.
This is what I didn't want to do, i.e introducing another daemon
into the system.
Best regards,
Zolt?n B?sz?rm?nyi
------------------------------
Message: 3
Date: Thu, 10 Mar 2016 09:54:14 +0100
From: Boszormenyi Zoltan <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/2] Extend NTP for exotic use cases
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
2016-03-08 12:39 keltez?ssel, Patrik Flykt ?rta:
> Hi,
>
> On Tue, 2016-03-08 at 09:59 +0100, [email protected] wrote:
>
>>> Hmm. Why can't you just set Timeservers.Configuration for the service in
>>> question? Or, if it is provisioned, Timeservers in the .config file?
>> Timeservers = ... is set in wired.config and despite that, the DHCP server
>> address (which is also the gateway) still occurs in the list of timeservers.
>>
>> Apparently, this occurs because the network gateway address is added
>> unconditionally to the list of timeservers.
>>
>> This patch would solve this part:
>>
>> diff --git a/src/timeserver.c b/src/timeserver.c
>> index f0d33e5..72e6ea9 100644
>> --- a/src/timeserver.c
>> +++ b/src/timeserver.c
>> @@ -204,17 +204,6 @@ GSList *__connman_timeserver_get_all(struct
>> connman_service *service)
>> for (i = 0; service_ts && service_ts[i]; i++)
>> list = __connman_timeserver_add_list(list, service_ts[i]);
>>
>> - network = __connman_service_get_network(service);
>> - if (network) {
>> - index = connman_network_get_index(network);
>> - service_gw = __connman_ipconfig_get_gateway_from_index(index,
>> - CONNMAN_IPCONFIG_TYPE_ALL);
>> -
>> - /* Then add Service Gateway to the list */
>> - if (service_gw)
>> - list = __connman_timeserver_add_list(list, service_gw);
>> - }
>> -
>> /* Then add Global Timeservers to the list */
>> timeservers = load_timeservers();
>>
>>
>> Why is this done in the first place?
> As a backup, should a badly implemented/configured home router decide to
> run a NTP server but forget to tell it to its DHCP clients.
In which case it still can be manually configured.
> So this one
> needs one more condition, add the gateway to the list if and only if it
> is not in the set of timeservers given already by DHCP.
I think the condition should rather depend on whether there is
a manual timeserver configuration.
Best regards,
Zolt?n B?sz?rm?nyi
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 5, Issue 13
**************************************
