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

Reply via email to