ntpd: servers stuck on .INIT

Question

I am trying to set up an NTP server for my local network, but ntpd refuses to sync with outer servers.

# ntptrace
localhost: stratum 16, offset 0.000000, synch distance 0.396285

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 31.135.95.60    .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 31.131.249.26   .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 91.122.42.73    .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 194.190.168.1   .INIT.          16 u    - 1024    0    0.000    0.000   0.000

The config I use is pretty much default:

# grep ^[^#] /etc/ntp.conf 
server 0.gentoo.pool.ntp.org
server 1.gentoo.pool.ntp.org
server 2.gentoo.pool.ntp.org
server 3.gentoo.pool.ntp.org
driftfile       /var/lib/ntp/ntp.drift
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]
restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap
disable monitor

Strange thing is that I have another NTP server inside the LAN, that works and synchronizes well, so I didn’t blame 123 UDP port, but to be sure I’ve opened it explicitly on the gateway where I’m trying to get up ntpd.

# iptables -L -n -v
Chain INPUT (policy ACCEPT 839K packets, 836M bytes)
 pkts bytes target     prot opt in     out     source               destination         
31696 3023K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
 3435  273K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     udp  --  !br0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:67 reject-with icmp-port-unreachable
    0     0 REJECT     udp  --  !br0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 reject-with icmp-port-unreachable
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:21
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:123
    0     0 DROP       tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpts:0:1023
  204 15504 DROP       udp  --  br1    *       0.0.0.0/0            0.0.0.0/0            udp dpts:0:1023
    0     0 DROP       tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2049
    0     0 DROP       udp  --  br1    *       0.0.0.0/0            0.0.0.0/0            udp dpt:2049
    0     0 DROP       tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpts:32765:32768
    0     0 DROP       udp  --  br1    *       0.0.0.0/0            0.0.0.0/0            udp dpts:32765:32768

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  br0    *       0.0.0.0/0            192.168.0.0/16      
21579 1859K ACCEPT     all  --  br0    *       192.168.0.0/16       0.0.0.0/0           
21307 6910K ACCEPT     all  --  br1    *       0.0.0.0/0            192.168.0.0/16      

Chain OUTPUT (policy ACCEPT 762K packets, 151M bytes)
 pkts bytes target     prot opt in     out     source               destination

br0 is LAN and br1 is WAN.

An attempt to connect to a stratum 2 server (that is seen on the other server, where ntpd works fine):

# ntpdate -d 95.213.132.250                                            
 2 May 07:35:30 ntpdate[9987]: ntpdate 4.2.8p2@1.3265-o Fri May  1 20:36:27 UTC 2015 (1)
transmit(95.213.132.250)
receive(95.213.132.250)
transmit(95.213.132.250)
receive(95.213.132.250)
transmit(95.213.132.250)
receive(95.213.132.250)
transmit(95.213.132.250)
receive(95.213.132.250)
server 95.213.132.250, port 123
stratum 2, precision -21, leap 00, trust 000
refid [95.213.132.250], delay 0.03688, dispersion 0.00314
transmitted 4, in filter 4
reference time:    d8eeccd9.08f19253  Sat, May  2 2015  7:11:05.034
originate timestamp: d8eed298.9d09bba6  Sat, May  2 2015  7:35:36.613
transmit timestamp:  d8eed298.9ae29d48  Sat, May  2 2015  7:35:36.605
filter delay:  0.04114  0.04720  0.04874  0.03688 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.004748 0.008231 0.008865 0.002733
         0.000000 0.000000 0.000000 0.000000
delay 0.03688, dispersion 0.00314
offset 0.002733

 2 May 07:35:36 ntpdate[9987]: adjust time server 95.213.132.250 offset 0.002733 sec

Trying to get some output from ntpd

# ntpd -gqd
 2 May 07:45:35 ntpd[20292]: ntpd 4.2.8p2@1.3265-o Fri May  1 20:36:26 UTC 2015 (1): Starting
 2 May 07:45:35 ntpd[20292]: Command line: ntpd -gqd
 2 May 07:45:35 ntpd[20292]: proto: precision = 0.051 usec (-24)
 2 May 07:45:35 ntpd[20292]: Listen and drop on 0 v4wildcard 0.0.0.0:123
 2 May 07:45:35 ntpd[20292]: Listen normally on 1 lo 127.0.0.1:123
 2 May 07:45:35 ntpd[20292]: Listen normally on 2 br0 192.168.0.1:123
 2 May 07:45:35 ntpd[20292]: Listen normally on 3 br0 192.168.0.9:123
 2 May 07:45:35 ntpd[20292]: Listen normally on 4 br0 192.168.0.17:123
 2 May 07:45:35 ntpd[20292]: Listen normally on 5 br1 192.168.42.250:123
 2 May 07:45:35 ntpd[20292]: Listening on routing socket on fd #22 for interface updates
 2 May 07:45:35 ntpd[20292]: restrict: ignoring line 51, address/host '[::1]' unusable.
^C 2 May 07:45:44 ntpd[20292]: ntpd exiting on signal 2 (Interrupt)
 2 May 07:45:44 ntpd[20292]: 46.8.40.31 local addr 192.168.42.250 -> <null>
 2 May 07:45:44 ntpd[20292]: 217.70.19.12 local addr 192.168.42.250 -> <null>
 2 May 07:45:44 ntpd[20292]: 89.208.145.140 local addr 192.168.42.250 -> <null>
 2 May 07:45:44 ntpd[20292]: 31.135.95.60 local addr 192.168.42.250 -> <null>

As it can be seen by ^C in the beginning, the daemon was iterrupted manually, because it doesn’t quit as it should (on the other sever ntpd quits after restrict message with reporting time slew)

Whatever I do, after many restarts, the drift doesn’t change:

# cat /var/lib/ntp/ntp.drift 
-7.037

Sounds like some type of firewall issue at your site. You might want to discuss this problem with your networking people. — mdpc, May 02 '15 at 06:13
You haven't yet demonstrated that the host firewall isn't the problem, iptables rules being order-dependent. Could you paste the *entire* output of `iptables -L -n -v` into your question? Also, the config line `restrict [::1]` is erroring, and should read `restrict -6 ::1`. — MadHatter, May 02 '15 at 07:27
Can you confirm that the successful run of ntpdate is on the same machine that ntpd is failing on? I'm not absolutely sure from your wording. — Paul Haldane, May 02 '15 at 07:32
@mdpc There’s no firewall above that, and I doubt that provider’s blocking 123 port. — tijagi, May 02 '15 at 16:51
@MadHatter that’d be the case, if ntp was built with ipv6 support. But it didn’t. And ntpd plainly sais that it has *ignored* the line. Both machines have ntp built without ipv6 and kernels with CONFIG_IPV6 not set. Also replaced iptables output with the one of `iptables -L -n -v.` — tijagi, May 02 '15 at 17:00
@PaulHaldane Yes, the output of ntpdate above is from the problem machine. It’s just the IP address of an NTP server was taken from the machine where ntpd works fine. — tijagi, May 02 '15 at 17:02

score 8 · Accepted Answer · answered May 03 '15 at 01:21

8

Your firewall rules do not permit NTP. The line

0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:123

is all very well, but NTP is a UDP service. Change the protocol, and things should get better. Your FORWARD rules are much more relaxed (essentially, permit any any) which is why the host inside the LAN syncs OK.

answered May 03 '15 at 01:21

MadHatter

79,770
20
184
232

The rule for ntp should allow outgoing traffic. Responses should be covered by a `ctstate RELATED,ESTABLISHED` input rule. – BillThor May 03 '15 at 02:37
1

@BillThor that would certainly be so - if there were such an `INPUT` rule in the chain above. – MadHatter May 03 '15 at 07:23

score 0 · Answer 2 · answered Apr 18 '23 at 23:34

I got similar problem with ntpd 4.2.8p15@1.3728-o under OpenWrt 22.03.3 In my case ntpd incorrectly binds to interfaces or process data from them. As a workaround you have to add to conf file:

interface listen ethX

Where ethX is the interface ntpd should listen answers from NTP servers

ntpd: servers stuck on .INIT

2 Answers2