* Marcel Holtmann > 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. 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. 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 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. Tore _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
