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.
But anyway, I'll give up on convicing you now.
Tore
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
