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 > [email protected] > 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: [email protected] | +43 (0)680 301 7167 http://software.tao.at
signature.asc
Description: OpenPGP digital signature
_______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
