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 [email protected] https://lists.connman.net/mailman/listinfo/connman
