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 0/1] Don't use gateway as timeserver (Chris Novakovic)
2. [PATCH 1/1] timeserver: don't use gateway as timeserver
(Chris Novakovic)
3. Re: Problem when creating a connman-vpn provider with dbus
net.connman.vpn.Manager.Create (Daniel Wagner)
4. Re: [PATCH] session: cleanup session_hash table on all error
cases. (Daniel Wagner)
5. Re: [PATCH] session_policy_local: Handling of failed_create
in get_uid_reply (Daniel Wagner)
6. Re: [PATCH 0/1] Don't use gateway as timeserver (Marcel Holtmann)
7. Re: [PATCH 0/1] Don't use gateway as timeserver (Daniel Wagner)
8. Re: [PATCH 0/1] Don't use gateway as timeserver (Chris Novakovic)
----------------------------------------------------------------------
Message: 1
Date: Thu, 3 May 2018 22:35:11 +0100
From: Chris Novakovic <[email protected]>
To: [email protected]
Subject: [PATCH 0/1] Don't use gateway as timeserver
Message-ID: <[email protected]>
On my local network, I've noticed a client using ConnMan sending NTP
packets to an IP address specified in DHCP option 3, even when that IP
address doesn't appear in DHCP option 42. Upon closer inspection, this
is because src/timeserver.c adds the gateway for a particular service to
its list of NTP servers. This behaviour is incorrect: the only
assumption that can be made about a gateway is that it functions as a
router. If an NTP server is also present on the gateway, it is the job
of the DHCP server to inform clients of this via DHCP option 42, which
ConnMan already (correctly) uses when building its list of NTP servers.
This patch stops ConnMan from automatically adding the IP addresses of
gateways to its list of NTP servers.
Chris Novakovic (1):
timeserver: don't use gateway as timeserver
src/timeserver.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
--
2.14.1
------------------------------
Message: 2
Date: Thu, 3 May 2018 22:35:12 +0100
From: Chris Novakovic <[email protected]>
To: [email protected]
Subject: [PATCH 1/1] timeserver: don't use gateway as timeserver
Message-ID: <[email protected]>
The only assumption that can be made about the gateway for a given
service is that it is a router; don't assume that it also functions as
an NTP server.
---
src/timeserver.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/src/timeserver.c b/src/timeserver.c
index 393c64c1..02a00a35 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -243,13 +243,11 @@ GSList *__connman_timeserver_add_list(GSList *server_list,
GSList *__connman_timeserver_get_all(struct connman_service *service)
{
GSList *list = NULL;
- struct connman_network *network;
char **timeservers;
char **service_ts;
char **service_ts_config;
- const char *service_gw;
char **fallback_ts;
- int index, i;
+ int i;
if (__connman_clock_timeupdates() == TIME_UPDATES_MANUAL)
return NULL;
@@ -268,17 +266,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();
--
2.14.1
------------------------------
Message: 3
Date: Fri, 4 May 2018 09:14:44 +0200
From: Daniel Wagner <[email protected]>
To: Thomas Achleitner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Problem when creating a connman-vpn provider with dbus
net.connman.vpn.Manager.Create
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 04/25/2018 11:31 AM, Thomas Achleitner wrote:
> i looked into it with one of our c programmers but unfortunately we
> couldn't find out why this happens...
Okay, I think I also pointed you in the wrong direction. I looked again
on the log files a bit closer. I am not sure anymore if the interaction
between ConnMan and the VPN daemon is right. It looks like the first
attempt leads to the situation that a service is created but not
configured. The second attempt gives ConnMan the missing information to
create the service. So this is the current theorie.
Can you try to log the interaction between the two daemons?
Just let monitor-connman and monitor-vpn run. Best with some timestamps
added, though you need to add a sys.stdout.flush() after the print in
monitor-connman and the same thing for monitor-vpn.
diff --git a/test/monitor-connman b/test/monitor-connman
index 1b3b84c74970..b51cc88b3f3a 100755
--- a/test/monitor-connman
+++ b/test/monitor-connman
@@ -2,6 +2,7 @@
import gobject
+import sys
import dbus
import dbus.mainloop.glib
@@ -55,6 +56,7 @@ from dbus.lowlevel import MethodCallMessage,
HANDLER_RESULT_NOT_YET_HANDLED
val = extract(name, value)
print "{%s} [%s] %s = %s" % (iface, path, name, val)
+ sys.stdout.flush()
def message_filter(connection, message):
if not isinstance(message, MethodCallMessage):
monitor-connman | ts '[%H:%M:%.S]' | tee connman.log
Thanks,
Daniel
------------------------------
Message: 4
Date: Fri, 4 May 2018 09:19:47 +0200
From: Daniel Wagner <[email protected]>
To: Harish Jenny K N <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] session: cleanup session_hash table on all error
cases.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Harish,
On 04/30/2018 01:58 PM, Harish Jenny K N wrote:
> Removing connman_session from 'session_hash' global hash
> table is needed for all error cases in
> session_policy_config_cb function.
> This patch moves the g_hash_table_remove call to handle
> in all error cases.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 5
Date: Fri, 4 May 2018 09:28:49 +0200
From: Daniel Wagner <[email protected]>
To: Harish Jenny K N <[email protected]>, [email protected]
Subject: Re: [PATCH] session_policy_local: Handling of failed_create
in get_uid_reply
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Harish,
On 05/03/2018 09:50 AM, Harish Jenny K N wrote:
> Cleanup of calling failed_create function inside get_uid_reply
> is done in this patch.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 6
Date: Fri, 4 May 2018 09:32:53 +0200
From: Marcel Holtmann <[email protected]>
To: Chris Novakovic <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/1] Don't use gateway as timeserver
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Chris,
> On my local network, I've noticed a client using ConnMan sending NTP
> packets to an IP address specified in DHCP option 3, even when that IP
> address doesn't appear in DHCP option 42. Upon closer inspection, this
> is because src/timeserver.c adds the gateway for a particular service to
> its list of NTP servers. This behaviour is incorrect: the only
> assumption that can be made about a gateway is that it functions as a
> router. If an NTP server is also present on the gateway, it is the job
> of the DHCP server to inform clients of this via DHCP option 42, which
> ConnMan already (correctly) uses when building its list of NTP servers.
>
> This patch stops ConnMan from automatically adding the IP addresses of
> gateways to its list of NTP servers.
but we are doing this on purpose. There is a good reason for this.
If you don?t want it that way, then at least this needs to be hidden behind a
main.conf option. Or you just set the NTP server for your network.
Regards
Marcel
------------------------------
Message: 7
Date: Fri, 4 May 2018 09:37:28 +0200
From: Daniel Wagner <[email protected]>
To: Marcel Holtmann <[email protected]>, Chris Novakovic
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/1] Don't use gateway as timeserver
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Marcel,
On 05/04/2018 09:32 AM, Marcel Holtmann wrote:
>> On my local network, I've noticed a client using ConnMan sending NTP
>> packets to an IP address specified in DHCP option 3, even when that IP
>> address doesn't appear in DHCP option 42. Upon closer inspection, this
>> is because src/timeserver.c adds the gateway for a particular service to
>> its list of NTP servers. This behaviour is incorrect: the only
>> assumption that can be made about a gateway is that it functions as a
>> router. If an NTP server is also present on the gateway, it is the job
>> of the DHCP server to inform clients of this via DHCP option 42, which
>> ConnMan already (correctly) uses when building its list of NTP servers.
>>
>> This patch stops ConnMan from automatically adding the IP addresses of
>> gateways to its list of NTP servers.
>
> but we are doing this on purpose. There is a good reason for this.
The initial commit doesn't really explain why we do this on purpose. Can
you remind me why we do it?
I was about to apply the patch right now. Luckily I saw your email in
time :)
Thanks,
Daniel
------------------------------
Message: 8
Date: Fri, 4 May 2018 17:06:16 +0100
From: Chris Novakovic <[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/1] Don't use gateway as timeserver
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Marcel,
On 04/05/2018 08:32, Marcel Holtmann wrote:
>> On my local network, I've noticed a client using ConnMan sending NTP
>> packets to an IP address specified in DHCP option 3, even when that IP
>> address doesn't appear in DHCP option 42. Upon closer inspection, this
>> is because src/timeserver.c adds the gateway for a particular service to
>> its list of NTP servers. This behaviour is incorrect: the only
>> assumption that can be made about a gateway is that it functions as a
>> router. If an NTP server is also present on the gateway, it is the job
>> of the DHCP server to inform clients of this via DHCP option 42, which
>> ConnMan already (correctly) uses when building its list of NTP servers.
>>
>> This patch stops ConnMan from automatically adding the IP addresses of
>> gateways to its list of NTP servers.
>
> but we are doing this on purpose. There is a good reason for this.
Could you elaborate on the reason, please? There's nothing in the
definition of a gateway that compels it to behave as a time server, and
I can't think of enough cases where they do to justify having this as
the default behaviour: I've yet to come across an ISP-supplied home
router that runs its own time server, and enterprises will typically run
time servers elsewhere in their network rather than dual-purposing the
gateway. That leaves SOHO routers/home routers running third-party
firmware, both of which are powerful enough to be configured to
correctly set DHCP option 42 if they also happen to run an NTP server.
> If you don?t want it that way, then at least this needs to be hidden behind a
> main.conf option.
Given the above, if a main.conf option is introduced for this, the
default behaviour ought to be not to send NTP traffic to the gateway, as
there's no prima facie reason for assuming it's capable of responding.
> Or you just set the NTP server for your network.
This doesn't address the problem, I'm afraid: src/timeserver.c adds the
gateway to the list of time servers regardless of whether DHCP option 42
is set, so if there is no NTP server in the network, ConnMan will still
send NTP traffic to the gateway.
Cheers,
Chris
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 31, Issue 3
**************************************
