How to synchronize time between two devices on a local network using NTPD, with one device serving as both client and server on separate interfaces?

Pool Development
1

I am using STM32MP1 based two devices which runs on Yocto platform(Kernel version 4.19.9). Among them one has two network interfaces (wlan0, wlan1) where wlan0 is used for connecting with internet servers & wlan1 will be acting as host network for another device to connect with this. I am using ntpd (version: ntpd 4.2.8p13@1.3847) for Time Synchronization. I had a common ntp.conf for both devices.

driftfile /var/lib/ntp/drift
server 127.127.1.0
fudge 127.127.1.0 stratum 14
restrict default

Also DHCP client configuration also same for both devices.

request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, host-name,
        netbios-name-servers, netbios-scope;

I neither had the specific servers mentioned in the ntp.conf file nor did my device’s DHCP client explicitly request ntp-servers. However, my primary device (which has two network interfaces) can still synchronize with the time servers provided by my Wi-Fi router.

But my secondary device can’t get time sync understandably it can’t reach time servers directly. The issue is the primary device is not acting as NTP server (on wlan1) for the secondary device to get timesync. I have used udhcpd on primary device for the secondary device to connect, below is the udhcpd.conf used,

start 192.168.10.100
end 192.168.10.200
interface wlan1
option subnet 255.255.255.0
option router 192.168.10.1
option lease 43200
option dns 192.168.10.1
option domain local

So I changed the ntp.conf files as below
#Primary device should act as an NTP client on wlan0 and as an NTP server on wlan1.

driftfile /var/lib/ntp/drift
server 127.127.1.0
fudge 127.127.1.0 stratum 14
interface listen all
restrict 192.168.10.0 mask 255.255.255.0 nomodify notrap

#Secondary device should act as NTP client only listen to primary device

driftfile /var/lib/ntp/drift
server 192.168.10.1 iburst minpoll 3 maxpoll 6
server 127.127.1.0
fudge 127.127.1.0 stratum 14
restrict 192.168.10.1

But still my secondary device’s time is not getting synced? what is the problem how to overcome this?

And I captured netstat output for both devices which seems to be Ok.
Primary device

root@stm32mp1-disco:~# netstat -tuln | grep 123
udp        0      0 192.168.10.1:123        0.0.0.0:*
udp        0      0 192.168.0.127:123       0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*
udp        0      0 fe80::a2cd:f3ff:fe38:2d7b:123 :::*
udp        0      0 fe80::a2cd:f3ff:fe38:2d7b:123 :::*
udp        0      0 ::1:123                 :::*
udp        0      0 :::123                  :::*

Secondary device

root@stm32mp1-disco:~# netstat -tuln | grep 123
udp        0      0 192.168.10.100:123      0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*
udp        0      0 fe80::a2cd:f3ff:fe35:a045:123 :::*
udp        0      0 ::1:123                 :::*
udp        0      0 :::123                  :::*

Please help me to overcome this.

2

@BalajiG , welcome to the community!

Did you check on the primary device, is there host firewall configuration blocking inbound NTP access?

3

You didn’t configure IPv6 access but it uses IPv6.
As such they don’t connect.

Try using both lines:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

Local networks are non-routable anyway, so no need to restrict to them if nobody routes them outside.
If you do not want to use IPv6, run ntpd with -4 parameter.

Edit /etc/default/ntp file and change NTPD_OPTS=‘-g’ to NTPD_OPTS=‘-g -4’

Then it will only listen to IPv4 and ignores IPv6 in total.

1 Like
4

The problem is you’ve told each device to synchronize to itself via the obsolete local clock driver 127.127.1.0 driver. The fallback functionality provided by that driver is now handled by a built-in orphan mode.

Modify both ntp.conf files to remove both lines referencing 127.127.1.0. Add to both files:

tos orphan 11

On the primary device with internet access add:

pool 2.pool.ntp.org. iburst
manycastserver 224.1.2.3

On the device without internet access add:

manycastclient 224.1.2.3 iburst maxpoll 7

Stop ntpd on both devices and delete /var/lib/ntp/drift as neither has actually calculated a meaningful frequency offset from UTC, and the 0.000 they have will dramatically slow the initial frequency correction.

Restart ntpd on the device with internet access and give it at least 15, preferably 30 minutes to find a cohort of pool servers and refine its frequency offset. Then restart the inside ntpd.

Using ntpd’s manycast server discovery scheme insulates the ntp.conf files from any need to know the IP addresses involved, and makes it easy to add additional devices with or without internet access. If you prefer, you could use IPv6 for the multicast addresses replacing 224.x.y.z with ff02::xyz or ff02::x:y:z etc.

Let us know how it goes for you.

2 Likes
5

Rather, the IPv6 multicast address for NTP is ff02::101. Likewise, the multicast IPv4 address for NTP is 224.0.1.1.

6

Yes, IANA reserved those multicast addresses for NTP. I recommend using different addresses intentionally, in case your multicast leaks to a wider audience. Very few, if any, upstream connections will relay multicast upstream without specific configuration, but in academic or research networks the network administrators may be using those reserved addresses and other uses might conflict. If you control your entire network up to the upstreams, and you know those upstreams are not propagating multicast from your network, you might choose to use the reserved NTP multicast addresses. You might also choose to have more than one self-organizing NTP subnet and use different addresses for each.

7

Those are sensible concerns, but your recommendation contradicts them. Only the 224.0.0.0/24 range is not routable. In this range, there are some addresses not yet assigned, within the 224.0.0.123-149 and 224.0.0.153-250 ranges, which should be chosen instead.

As for the IPv6 NTP multicast address, since its scope is local, it’s not routable by definition.

Finally, the original scenario is totally under control.

9

Thanks @Bas

My issue is resolved after using

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

On both devices. Also, I removed restrict line for local network based on your suggestion.
Primary device:

driftfile /var/lib/ntp/drift
server 127.127.1.0
fudge 127.127.1.0 stratum 14
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

Secondary device:

driftfile /var/lib/ntp/drift
server 192.168.10.1 iburst minpoll 3 maxpoll 6
server 127.127.1.0
fudge 127.127.1.0 stratum 14
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

Thank you again. Have a good day!

Regards,
Balaji G.

1 Like
10

Thank you @NTPman,

I confirmed that host firewall configuration is not blocking inbound NTP access.

11

Hi @davehart

Thank you so much for providing another way of solution. It worked.

Have a great day!

Regards,
Balaji G.

12

Thanks @ebahapo for your in-depth clarification.

13

Just for future reference of others reading this post, I want to clarify that IPv6 had nothing to do with his problem. All of the original poster’s configuration files in this thread, including the initial one to which you referred, used only IPv4 addresses not hostnames, so no IPv6 traffic or settings came into play.

I suspect you had in mind how DNS resolution of hostnames tends to prefer IPv6 over IPv4, and some systems have only local IPv6 but internet IPv4. Combined with ntpd using only the first IP address returned from a DNS lookup, this could result in server some.example.org spinning up a useless IPv6 association and staying with it forever, while either invoking ntpd -4 or instead using server -4 some.example.org would work around the problem.

1 Like