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
