[PATCH 1/3] Do not assume the gateway is also a NTP server
This patch prevents connman from [ab]using the default gateway as a
fallback NTP server. The rationale for the previous behaviour was
apparently that if the DHCP server does not advertise an NTP server
option, then attempting to use the default gateway has at least a
non-zero chance of success. However as there's no requirement that a
router also must run a NTP service, there's also a non-zero chance of
failure, which would lead to junk packets being transmitted.
This reverts commit bbd1981. Since that time, the "FallbackTimeservers"
config option has been implemented, which is a much better way to deal
with the eventuality of not receiving any NTP server list via DHCP.
Closes CM-674.
---
src/timeserver.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/src/timeserver.c b/src/timeserver.c
index f0d33e5..d719d08 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -179,13 +179,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;
@@ -204,17 +202,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.1.0
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
Hi Tore, > This patch prevents connman from [ab]using the default gateway as a > fallback NTP server. The rationale for the previous behaviour was > apparently that if the DHCP server does not advertise an NTP server > option, then attempting to use the default gateway has at least a > non-zero chance of success. However as there's no requirement that a > router also must run a NTP service, there's also a non-zero chance of > failure, which would lead to junk packets being transmitted. > > This reverts commit bbd1981. Since that time, the "FallbackTimeservers" > config option has been implemented, which is a much better way to deal > with the eventuality of not receiving any NTP server list via DHCP. it is actually not. There are cases where you can reach the gateway, but not reach anything else. So I am fine with making this behavior optional based on a main.conf setting, but just removing it is not an option. We do want ConnMan to figure things out by itself and FallbackTimeservers are a bad choice here. So if you want to not fallback to a gateway as NTP server, then please add a configuration option in main.conf that allows disabling this behavior. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
* Marcel Holtmann > Hi Tore, > > > This patch prevents connman from [ab]using the default gateway as a > > fallback NTP server. The rationale for the previous behaviour was > > apparently that if the DHCP server does not advertise an NTP server > > option, then attempting to use the default gateway has at least a > > non-zero chance of success. However as there's no requirement that a > > router also must run a NTP service, there's also a non-zero chance of > > failure, which would lead to junk packets being transmitted. > > > > This reverts commit bbd1981. Since that time, the "FallbackTimeservers" > > config option has been implemented, which is a much better way to deal > > with the eventuality of not receiving any NTP server list via DHCP. > > it is actually not. There are cases where you can reach the gateway, > but not reach anything else. So I am fine with making this behavior > optional based on a main.conf setting, but just removing it is not an > option. We do want ConnMan to figure things out by itself and > FallbackTimeservers are a bad choice here. But if the gateway does is unable to provide you internet connectivity, the chances of it being able to provide a usable NTP service is pretty much next to nil anyway. Note that my patches does not preclude the DHCP server from advertising the gateway (or any other node) as an NTP server. If it does, then the FallbackTimeservers doesn't come into play, the advertised NTP server(s) will be what connman ends up using no matter what. Defaulting to using the gateway as an NTP server - without having any sort of indication that the gateway actually *is* an NTP server (read: DHCP option 42) - rather than using public known NTP servers, can only be a useful thing to do if all of the following conditions are met, as I see it: 1) An NTP service happens to be running on the gateway 2) The DHCP server, in spite of #1, does not advertise the gateway (or any other node for that matter) as an NTP server in DHCP option 42 3) The gateway does not have internet connectivity (i.e., public NTP servers are unreachable) 4) The gateway is equipped with an atomic clock or a GPS receiver or some other device or mechanism that ensures it is able to keep time in spite of #3 It's a rather far-fetched scenario IMHO. This one is much more plausible: 1) The gateway does provide internet connectivity 2) The gateway doesn't run an NTP service 3) The DHCP server doesn't advertise any NTP servers In this case, my patches would ensure that you get a working NTP server configuration. Current connman fails miserably, and just ends up spamming the default gateway with useless packets while doing so. Tore ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
Hi Tore, >>> This patch prevents connman from [ab]using the default gateway as a >>> fallback NTP server. The rationale for the previous behaviour was >>> apparently that if the DHCP server does not advertise an NTP server >>> option, then attempting to use the default gateway has at least a >>> non-zero chance of success. However as there's no requirement that a >>> router also must run a NTP service, there's also a non-zero chance of >>> failure, which would lead to junk packets being transmitted. >>> >>> This reverts commit bbd1981. Since that time, the "FallbackTimeservers" >>> config option has been implemented, which is a much better way to deal >>> with the eventuality of not receiving any NTP server list via DHCP. >> >> it is actually not. There are cases where you can reach the gateway, >> but not reach anything else. So I am fine with making this behavior >> optional based on a main.conf setting, but just removing it is not an >> option. We do want ConnMan to figure things out by itself and >> FallbackTimeservers are a bad choice here. > > But if the gateway does is unable to provide you internet connectivity, > the chances of it being able to provide a usable NTP service is pretty > much next to nil anyway. not in a corporate environment where you might have a central DHCP, but you might to use the NTP server closest to you. > Note that my patches does not preclude the DHCP server from advertising > the gateway (or any other node) as an NTP server. If it does, then the > FallbackTimeservers doesn't come into play, the advertised NTP server(s) > will be what connman ends up using no matter what. Falling back to the gateway as NTP server is when the DHCP server does not provide any NTP servers. As stated above, there are corporate enterprise networks where this make total sense. > Defaulting to using the gateway as an NTP server - without having any > sort of indication that the gateway actually *is* an NTP server (read: > DHCP option 42) - rather than using public known NTP servers, can only > be a useful thing to do if all of the following conditions are met, as > I see it: > > 1) An NTP service happens to be running on the gateway > 2) The DHCP server, in spite of #1, does not advertise the gateway (or > any other node for that matter) as an NTP server in DHCP option 42 > 3) The gateway does not have internet connectivity (i.e., public NTP > servers are unreachable) > 4) The gateway is equipped with an atomic clock or a GPS receiver or > some other device or mechanism that ensures it is able to keep time in > spite of #3 As I said, many corporate networks fulfill that list. It will not be atomic clock, but all the routers will have a properly synchronized time. > It's a rather far-fetched scenario IMHO. This one is much more > plausible: > > 1) The gateway does provide internet connectivity > 2) The gateway doesn't run an NTP service > 3) The DHCP server doesn't advertise any NTP servers > > In this case, my patches would ensure that you get a working NTP server > configuration. Current connman fails miserably, and just ends up > spamming the default gateway with useless packets while doing so. I am fine with providing an option to disable this functionality we have right now. However it is a main.conf option and can not just be replaced with FallbackTimeservers. That is a different thing. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
* Marcel Holtmann > > But if the gateway does is unable to provide you internet > > connectivity, the chances of it being able to provide a usable NTP > > service is pretty much next to nil anyway. > > not in a corporate environment where you might have a central DHCP, > but you might to use the NTP server closest to you. > > > Note that my patches does not preclude the DHCP server from > > advertising the gateway (or any other node) as an NTP server. If it > > does, then the FallbackTimeservers doesn't come into play, the > > advertised NTP server(s) will be what connman ends up using no > > matter what. > > Falling back to the gateway as NTP server is when the DHCP server > does not provide any NTP servers. As stated above, there are > corporate enterprise networks where this make total sense. Hi Marcel, Okay, I admit it is possible to intentionally build a corporate network where it would be beneficial to treat DHCP option 3 essentially as an additional option 42 (I was thinking mostly about broken residental gateways when writing my previous issue). That said, I am really at a loss as to why someone would actually want to do so... First: Why exactly wouldn't the administrator of the DHCP server in question use option 42 to advertise the NTP server address to the clients (which of course could be the exactly same address as the default router address he advertises in option 3)? Second: If you're an administrator of a corporate DHCP server and want your clients to use the default gateway as the NTP server, there's no way around using option 42 anyway - because, to the best of my knowledge, connman is the only connection manager / OS to blindly assume that any default router will also provide NTP service. Third: If you're an administrator of a corporate DHCP server and you *do* use option 42 to make your client use some other NTP server (i.e., not the default router), you certainly do *not* want connman to second-guess that and blindly add the router as an NTP server anyway. This is what I noticed happening in my network, and what prompted me to submit an issues/send patches. I could of course improve this third issue by making connman not add the default router as an NTP server if option 42 was received. However IMHO that would only make the behaviour "less wrong", it would certainly not be "right". The bottom line is that the NTP service and default router addresses are two completely independent things that should not be confused, just like you shouldn't confuse the addresses of the DNS service, DHCP service, or any of the other 100+ different things it is possible to advertise in DHCP. While it is certainly possible to build networks where multiple services are provided by the same node (and there's nothing wrong with doing so), you cannot assume that this is going to be true in the general case or even in a majority of cases. Tore ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
Hi Tore, >>> But if the gateway does is unable to provide you internet >>> connectivity, the chances of it being able to provide a usable NTP >>> service is pretty much next to nil anyway. >> >> not in a corporate environment where you might have a central DHCP, >> but you might to use the NTP server closest to you. >> >>> Note that my patches does not preclude the DHCP server from >>> advertising the gateway (or any other node) as an NTP server. If it >>> does, then the FallbackTimeservers doesn't come into play, the >>> advertised NTP server(s) will be what connman ends up using no >>> matter what. >> >> Falling back to the gateway as NTP server is when the DHCP server >> does not provide any NTP servers. As stated above, there are >> corporate enterprise networks where this make total sense. > > Hi Marcel, > > Okay, I admit it is possible to intentionally build a corporate network > where it would be beneficial to treat DHCP option 3 essentially as an > additional option 42 (I was thinking mostly about broken residental > gateways when writing my previous issue). That said, I am really at a > loss as to why someone would actually want to do so... > > First: Why exactly wouldn't the administrator of the DHCP server in > question use option 42 to advertise the NTP server address to the > clients (which of course could be the exactly same address as the > default router address he advertises in option 3)? that is pretty simple. The DHCP server are centrally managed. However they do not want NTP going through the whole network. So it should terminate at the gateway. I have seen this kind of networks. So they exist and we have used ConnMan in these networks. > Second: If you're an administrator of a corporate DHCP server and want > your clients to use the default gateway as the NTP server, there's no > way around using option 42 anyway - because, to the best of my > knowledge, connman is the only connection manager / OS to blindly > assume that any default router will also provide NTP service. Forgot what an administrator might thing. This is a reality and so get on board with it. > Third: If you're an administrator of a corporate DHCP server and you > *do* use option 42 to make your client use some other NTP server (i.e., > not the default router), you certainly do *not* want connman to > second-guess that and blindly add the router as an NTP server anyway. > This is what I noticed happening in my network, and what prompted me to > submit an issues/send patches. This one sounds like a bug in ConnMan. Worth while fixing. > I could of course improve this third issue by making connman not add > the default router as an NTP server if option 42 was received. However > IMHO that would only make the behaviour "less wrong", it would > certainly not be "right". The bottom line is that the NTP service and > default router addresses are two completely independent things that > should not be confused, just like you shouldn't confuse the addresses > of the DNS service, DHCP service, or any of the other 100+ different > things it is possible to advertise in DHCP. If the DHCP provides you an option 42, then second guessing that is wrong. In that case only the FallbackTimeservers should be allowed to do an overwrite. > While it is certainly possible to build networks where multiple > services are provided by the same node (and there's nothing wrong with > doing so), you cannot assume that this is going to be true in the > general case or even in a majority of cases. We can argue this for a long time. However I am not breaking existing behavior. As I said before, you can have a main.conf option to just disable it in your installations. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
Do you really want to special-case every single broken network setup under the sun? (And does any networking client apart from connman support this? I think the usual suspects in corporate networks – namely Windows and maybe RHEL with NetworkManager – don't.) On 2015-03-24 04:38, Marcel Holtmann wrote: > Hi Tore, > But if the gateway does is unable to provide you internet connectivity, the chances of it being able to provide a usable NTP service is pretty much next to nil anyway. >>> >>> not in a corporate environment where you might have a central DHCP, >>> but you might to use the NTP server closest to you. >>> Note that my patches does not preclude the DHCP server from advertising the gateway (or any other node) as an NTP server. If it does, then the FallbackTimeservers doesn't come into play, the advertised NTP server(s) will be what connman ends up using no matter what. >>> >>> Falling back to the gateway as NTP server is when the DHCP server >>> does not provide any NTP servers. As stated above, there are >>> corporate enterprise networks where this make total sense. >> >> Hi Marcel, >> >> Okay, I admit it is possible to intentionally build a corporate network >> where it would be beneficial to treat DHCP option 3 essentially as an >> additional option 42 (I was thinking mostly about broken residental >> gateways when writing my previous issue). That said, I am really at a >> loss as to why someone would actually want to do so... >> >> First: Why exactly wouldn't the administrator of the DHCP server in >> question use option 42 to advertise the NTP server address to the >> clients (which of course could be the exactly same address as the >> default router address he advertises in option 3)? > > that is pretty simple. The DHCP server are centrally managed. However they do > not want NTP going through the whole network. So it should terminate at the > gateway. I have seen this kind of networks. So they exist and we have used > ConnMan in these networks. > >> Second: If you're an administrator of a corporate DHCP server and want >> your clients to use the default gateway as the NTP server, there's no >> way around using option 42 anyway - because, to the best of my >> knowledge, connman is the only connection manager / OS to blindly >> assume that any default router will also provide NTP service. > > Forgot what an administrator might thing. This is a reality and so get on > board with it. > >> Third: If you're an administrator of a corporate DHCP server and you >> *do* use option 42 to make your client use some other NTP server (i.e., >> not the default router), you certainly do *not* want connman to >> second-guess that and blindly add the router as an NTP server anyway. >> This is what I noticed happening in my network, and what prompted me to >> submit an issues/send patches. > > This one sounds like a bug in ConnMan. Worth while fixing. > >> I could of course improve this third issue by making connman not add >> the default router as an NTP server if option 42 was received. However >> IMHO that would only make the behaviour "less wrong", it would >> certainly not be "right". The bottom line is that the NTP service and >> default router addresses are two completely independent things that >> should not be confused, just like you shouldn't confuse the addresses >> of the DNS service, DHCP service, or any of the other 100+ different >> things it is possible to advertise in DHCP. > > If the DHCP provides you an option 42, then second guessing that is wrong. In > that case only the FallbackTimeservers should be allowed to do an overwrite. > >> While it is certainly possible to build networks where multiple >> services are provided by the same node (and there's nothing wrong with >> doing so), you cannot assume that this is going to be true in the >> general case or even in a majority of cases. > > We can argue this for a long time. However I am not breaking existing > behavior. As I said before, you can have a main.conf option to just disable > it in your installations. > > Regards > > Marcel > > ___ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman > -- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas Systemadministrator TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167 http://software.tao.at signature.asc Description: OpenPGP digital signature ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
Hi,
On Tue, 2015-03-24 at 02:20 +0100, Tore Anderson wrote:
> I could of course improve this third issue by making connman not add
> the default router as an NTP server if option 42 was received.
That is what I had in mind after the discussion in JIRA on CM-674.
> However IMHO that would only make the behaviour "less wrong", it would
> certainly not be "right". The bottom line is that the NTP service and
> default router addresses are two completely independent things that
> should not be confused, just like you shouldn't confuse the addresses
> of the DNS service, DHCP service, or any of the other 100+ different
> things it is possible to advertise in DHCP.
First of all, NTP and default gateway roles are not confused. The
gateway has always been intentionally added to the set of NTP servers to
serve as a decent default entry that is as close as possible. This
behavior has nothing to do with any RFCs or other documents, it's just
an observation that is known to work in real life.
The code is written to add service specific NTP servers first, then the
gateway and last but not least the fallback NTP servers. Here the
service specific NTP servers are either obtained via DHCP or manually
set. When ConnMan starts, it takes the first server from the list into
use and proceeds to the next one only if there were no replies from the
current one. So if ConnMan ends up sending NTP packets to the gateway,
it means there were no service specific NTP servers or then the service
specific NTP servers were incorrectly set up. If the default gateway
does not answer, the fallback NTP servers are used next.
Instead of adding more options to main.conf, the following oneliner
makes the situation a bit smarter:
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -205,7 +205,7 @@ GSList *__connman_timeserver_get_all(struct
connman_service *service)
list = __connman_timeserver_add_list(list,
service_ts[i]);
network = __connman_service_get_network(service);
- if (network) {
+ if (!service_ts && network) {
index = connman_network_get_index(network);
service_gw =
__connman_ipconfig_get_gateway_from_index(index,
CONNMAN_IPCONFIG_TYPE_ALL);
HTH,
Patrik
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
On Tue, 2015-03-24 at 09:32 +0100, Sven Schwedas wrote: > Do you really want to special-case every single broken network setup > under the sun? As this case is existing behavior, I'm not going to remove it and break things for users just because. > (And does any networking client apart from connman support this? I > think the usual suspects in corporate networks – namely Windows and > maybe RHEL with NetworkManager – don't.) +1 for ConnMan on this particular subject then. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
On 2015-03-24 09:46, Patrik Flykt wrote:
>
> The code is written to add service specific NTP servers first, then the
> gateway and last but not least the fallback NTP servers. Here the
> service specific NTP servers are either obtained via DHCP or manually
> set. When ConnMan starts, it takes the first server from the list into
> use and proceeds to the next one only if there were no replies from the
> current one. So if ConnMan ends up sending NTP packets to the gateway,
> it means there were no service specific NTP servers or then the service
> specific NTP servers were incorrectly set up. If the default gateway
> does not answer, the fallback NTP servers are used next.
Wouldn't it model the proposed use case better if the fallback servers
were tried first, and only if those don't work (because we're in a
firewalled corporate network, e.g.) the gateway? There's loads of setups
where no NTP is set, but external servers not filtered – hotspots,
consumer wifi APs, 3G, … –, and this would waste time trying to sync
with the gateway.
>
> Instead of adding more options to main.conf, the following oneliner
> makes the situation a bit smarter:
>
> --- a/src/timeserver.c
> +++ b/src/timeserver.c
> @@ -205,7 +205,7 @@ GSList *__connman_timeserver_get_all(struct
> connman_service *service)
> list = __connman_timeserver_add_list(list,
> service_ts[i]);
>
> network = __connman_service_get_network(service);
> - if (network) {
> + if (!service_ts && network) {
> index = connman_network_get_index(network);
> service_gw =
> __connman_ipconfig_get_gateway_from_index(index,
> CONNMAN_IPCONFIG_TYPE_ALL);
>
>
> HTH,
>
> Patrik
>
>
> ___
> connman mailing list
> connman@connman.net
> https://lists.connman.net/mailman/listinfo/connman
>
--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167
http://software.tao.at
signature.asc
Description: OpenPGP digital signature
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
Hi again Marcel,
* Marcel Holtmann
> > First: Why exactly wouldn't the administrator of the DHCP server in
> > question use option 42 to advertise the NTP server address to the
> > clients (which of course could be the exactly same address as the
> > default router address he advertises in option 3)?
>
> that is pretty simple. The DHCP server are centrally managed. However
> they do not want NTP going through the whole network. So it should
> terminate at the gateway.
But that doesn't even begin to explain why the DHCP server operator
wouldn't use option 42. If he wants the behaviour you describe, the
obvious way to get is to configure the DHCP server something like this:
# VLAN 10 in location A
subnet 192.168.10.0 netmask 255.255.255.0 {
option routers 192.168.10.1;
option ntp-servers 192.168.10.1;
[...]
}
# VLAN 20 in location B
subnet 192.168.20.0 netmask 255.255.255.0 {
option routers 192.168.20.1;
option ntp-servers 192.168.20.1;
[...]
}
In this case, the NTP traffic will not be going through the whole
network, it will terminate at the gateway in each each VLAN. Also, it
has the added benefit that it will work with any standards compliant
client, not just ConnMan.
If this behaviour is desired, why omit option 42? I don't get it.
> I have seen this kind of networks. So they exist and we have used
> ConnMan in these networks.
Right, but such a network would be making an assumption that the
clients implement this non-standard NTP server fallback algorithm. That
assumption would be however faulty, with just one exception: ConnMan.
Just because one broken network exists, that does not mean that every
network in the world is broken in the same way, but that's precisely
what ConnMan is assuming now. Two wrongs might make a right on your
network, but not on everyone else's...
Catering to networks with such broken assumptions doesn't really scale,
either. You can just as easily build a network that assumes that
clients use the advertised DNS server (option 6) as the NTP server when
option 42 is omitted. And so on for every imaginable combination of
options. Even though such networks might exist, and have ConnMan
clients on them, I really hope that you won't be adding any more of
these hard-coded assumptions à la «option X might really be option Y».
> > Third: If you're an administrator of a corporate DHCP server and you
> > *do* use option 42 to make your client use some other NTP server
> > (i.e., not the default router), you certainly do *not* want connman
> > to second-guess that and blindly add the router as an NTP server
> > anyway. This is what I noticed happening in my network, and what
> > prompted me to submit an issues/send patches.
>
> This one sounds like a bug in ConnMan. Worth while fixing.
I'll send a patch, see below.
> If the DHCP provides you an option 42, then second guessing that is
> wrong. In that case only the FallbackTimeservers should be allowed to
> do an overwrite.
That doesn't sound right to me... You meant that if there's an option
42 in DHCP, then FallbackTimeservers should *not* be allowed to
overwrite it, right?
At least that would be in line with what the documentation says:
«[FallbackTimeservers] are used for NTP sync when there are no
timeserver set by the user or by the service».
Would you also agree that FallbackTimeservers should have a higher
priority than the default router fallback? At least, that's what I'd
expect based on the documentation, i.e., if I as a user explicitly sets
one or more FallbackTimeservers I would not want the ConnMan's default
router fallback (which cannot be disabled) to preempt that.
The default router fallback currently has a higher preference than the
Global Timeservers list. That also seems wrong. Agreed?
So what I'm proposing is to send an updated patch that changes the list
of time servers to the following (in order of preference):
1. Any NTP servers advertised in DHCP
2. Any configured Global Timeservers
3. Any configured FallbackTimeservers (iff #1 + #2 yields an empty set)
4. Any service gateways (iff #1 + #2 + #3 yields an empty set)
Would that be acceptable?
> I am not breaking existing behavior.
Existing behaviour *is* broken, as it is not standards compliant, and
makes ConnMan end up trying to use what essentially amounts to a
random address as an NTP server. If it actually works, it's just pure
luck. See RFC 2132 section 3.5. There's nothing to the effect of
«clients may also interpret this option as an additional option 42».
Section 8.3 describes option 42, and there's no «in the absense of this
option, clients may use option 3 instead». The two options are
completely orthogonal, just like the actual services they describe.
They're not even in the same chapter of the RFC.
If you really want a combo "3+42" option so much, the standards
compliant way of doing that would be to use an option in the private
range (224-254), or of course by going through the IETF to get an
IANA-assigned option.
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
On Tue, 2015-03-24 at 11:07 +0100, Tore Anderson wrote: > If this behaviour is desired, why omit option 42? I don't get it. Me neither. > Catering to networks with such broken assumptions doesn't really scale, > either. You can just as easily build a network that assumes that > clients use the advertised DNS server (option 6) as the NTP server when > option 42 is omitted. Here's the leaky point where you have it wrong. The code does not ever supply DHCP gateways as NTP servers. Or provide any other options as something they're not for that matter. The default gateway is added to the list as a possible NTP server in a completely separate part of the code that has nothing whatsoever to do with DHCP. It does that also for manually configured IP addresses, or any other address classes for that matter. > At least that would be in line with what the documentation says: > «[FallbackTimeservers] are used for NTP sync when there are no > timeserver set by the user or by the service». The code corresponds to the documentation. The current code uses FallbackTimeservers after all other timeservers have been tried first. > Existing behaviour *is* broken, as it is not standards compliant, and > makes ConnMan end up trying to use what essentially amounts to a > random address as an NTP server. If it actually works, it's just pure > luck. See RFC 2132 section 3.5. Adding the default gateway as a possible NTP server outside of DHCP code has nothing to do with RFC 2132 and does therefore not break any standards. HTH, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] Do not assume the gateway is also a NTP server
Hi Patrik, * Patrik Flykt > Here's the leaky point where you have it wrong. > > The code does not ever supply DHCP gateways as NTP servers. Or provide > any other options as something they're not for that matter. > > The default gateway is added to the list as a possible NTP server in a > completely separate part of the code that has nothing whatsoever to do > with DHCP. It does that also for manually configured IP addresses, or > any other address classes for that matter. Right. But you're still adding a possible NTP server which you have absolutely zero knowledge whether or not actually is an NTP server. The fact that you've observed this to be the case on your network (or "a network") does not mean that it is the case on every network. You will in all likelihood also find networks where the DNS server (whether or not it came from DHCP or static config) will happily respond to NTP queries, and you'll probably find networks where "1.1.1.1" does, and so on, but that does not translate into sensible default behaviour for a general purpose connection manager that's expected to Do The Right Thing on any network in the world. > > At least that would be in line with what the documentation says: > > «[FallbackTimeservers] are used for NTP sync when there are no > > timeserver set by the user or by the service». > > The code corresponds to the documentation. The current code uses > FallbackTimeservers after all other timeservers have been tried first. So you consider the default router fallback as "a timeserver set by the service"? If so, that doesn't correspond well with the comments in timeserver.c, which makes a clear distinction between "Service Timeservers" (lines 195 and 203) and the "Service Gateway" (line 213). Semantics aside, from a user's point of view the actual outcome is in any case unexpected, because the service gateway fallback appears to be completely undocumented. If I explicitly configure a global time server, I'd expect it to be used in preference to any built-in fallback. Same thing if I explicitly configure a FallbackTimeserver; I do not expect ConnmMan to go out and try some other hard-coded fallback in preference to what I explicitly configured myself. It could even be harmful to do so, if the service gateway actually does respond to NTP queries but happens to be a falseticker. So I'll ask again if the updated patch I proposed is acceptable? It would retain the service gateway as a last-resort fallback timeserver, so it will not break the use case you and Marcel has described, but it would at the same time ensure that any NTP servers that are explicitly provisioned by the network or the user will be preferred. The assumption is that if the network or the user is explicit about which NTP servers should be used, then ConnMan should not second-guess it. > Adding the default gateway as a possible NTP server outside of DHCP > code has nothing to do with RFC 2132 and does therefore not break any > standards. Well, if you look at it that way, neither does adding 12.34.56.78 or any other arbitrary IP address... Tore ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
