[CM-674] DHCPv4 default router is added to NTP server list Created: 20/Mar/15  Updated: 17/May/16  Resolved: 12/May/15

Status: Closed
Project: Connection Manager
Component/s: ConnMan Core
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Undecided
Reporter: Anderson Tore Assignee: Flykt Patrik
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Jolla SailfishOS (Yliaavanlampi) (armv7hl)
Mer release 0.2011 (Mer)


When connecting to a wireless network using DHCPv4, addresses in the Router DHCPv4 Option (3) gets added to connman's Timeservers list. Any timeservers in the NTP Servers Option (42) are also added, so the Timeservers list ends up containing both:

[nemo@Jolla ~]$ connmanctl services wifi_5056a8017b39_524c_managed_psk | grep Timeservers
  Timeservers = [,,, 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org ]
  Timeservers.Configuration = [  ]

The DHCPv4 server message that configured this connection does however not advertise as an NTP server, only as a router:

$ tshark -r dhcpv4.pcap -V
    Option: (42) Network Time Protocol Servers
        Length: 8
        Network Time Protocol Server: (
        Network Time Protocol Server: (
    Option: (3) Router
        Length: 4
        Router: (

It would appear that this commit intentionally introduced this broken behaviour.

Comment by Flykt Patrik [ 23/Mar/15 ]

The default gateway is added to the list of possible timeservers as it more often than not provides NTP services anyway and therefore works as a decent fallback option. Adding it to the list was intentional and the desired thing to do as a workaround for a bunch of networking equipment.

Perhaps the feature here is not to add the default gateway if DHCP provided NTP servers are available? I have nothing against accepting such a patch if submitted to the mailing list.

Comment by Anderson Tore [ 23/Mar/15 ]

That the default gateway provides NTP service is a completely faulty assumption. There is zero coupling between NTP service and gateway service; it is perfectly legitimate for a device to forward packets but not respond to NTP queries, just as it is perfectly legitimate for a NTP device to not forward packets. Assuming that an IP address advertised in a service-specific DHCP option (be it NTP server, standard router, default router, syslog server, DNS server, quote server, LPR server, whatever) is automatically capable of delivering another arbitrary service is quite simply broken behaviour.

NTP servers are advertised in DHCPv4 option 42 only. If there is no DHCPv4 option 42 being advertised, then that means that no NTP servers are being advertised. You can't just pick another - essentially random - IP address and assume that it will be able to answer NTP queries. Instead, use pool.ntp.org for that.

I could send you a patch to simply revert commit bbd1981, as that's really the only correct way to go about fixing this bug...

Comment by Flykt Patrik [ 23/Mar/15 ]

As said, that commit it is a workaround for a set of not so perfectly designed residential gateways. It has been needed in the past, so just reverting a patch won't help those who unknowingly depend on it. My suggestion still is to add the gateway in the case no NTP servers are provided by DHCP.

Comment by Anderson Tore [ 23/Mar/15 ]

It would be much, much better to use the NTP Pool project (see http://www.pool.ntp.org/en/) to provide any fallback NTP server(s), that's after all exactly what it's made for - it provides you with a set of working NTP servers in your geographic vicinity. Would you accept such a patch?

There's on the other hand no guarantee that a "not so perfectly designed residential gateway" contains an NTP server. Most likely, it does not.

Comment by Flykt Patrik [ 23/Mar/15 ]

YMMV, indeed.

Generated at Fri Apr 03 20:33:46 GMT 2020 using Jira 8.8.0#808000-sha1:e2c7e59ae165efc6ad6b529150e24d091b9947bf.