Openntpd

Hi,

I am just pulling my hairs to get openntpd running, just no luck with so much troubleshooting and breaking my head over this issue after a fresh installation of Freebsd FreeBSD 10.

My ntpd.conf file :

Code:
# Addresses to listen on (ntpd does not listen by default)
#listen on *
#listen on ::1
listen on 192.168.1.1

# sync to a single server
#server ntp.example.org

# use a random selection of NTP Pool Time Servers
# see http://support.ntp.org/bin/view/Servers/NTPPoolServers

server 1.in.pool.ntp.org
server 1.asia.pool.ntp.org
server 0.asia.pool.ntp.org

The rule for NTP on my pf.conf is the following:
Code:
pass out quick on $ext_if inet proto udp from any to any  port ntp
pass out quick on $ext_if inet proto tcp from any to any  port ntp
I tried even disabling the PF firewall but still things dont don't work, I removed openntpd and tried to set the time with ntpdate but I get the following error:
Code:
ntpdate[35410]: no server suitable for synchronization found

I am really getting tired trying to get the time set for the server, so right now I am trying to see why ntpdate is not setting time on my server and once I am able to resolve I will proceed with openntpd. What am I doing wrong or any clue why ntpdate is not working?

Thanks and regards,
dotfish
 
Hello,

I believe that ntpdate should be used with an argument, for instance ntpdate 1.in.pool.ntp.org. Did you try that? Then, what is the path of your ntpd.conf file? The one in /etc/ntp.conf is for the included ntpd daemon, while /usr/local/etc/ntpd.conf is for openntpd. It could be like this:

Code:
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

For it to work you have to modify /etc/rc.conf:
Code:
ntpd_enable="NO"
openntpd_enable="YES"
openntpd_flags="-s" # sync at boot and afterward

Is your configuration similar?

Guillaume.
 
You can use ntpdate(8) without root privileges to test whether the NTP server responds and what the time adjustment would be if you use the -q (query) flag:

Code:
freebsd10 ~ % ntpdate -q 1.in.pool.ntp.org
server 120.88.46.10, stratum 2, offset -0.011305, delay 0.18306
server 123.108.200.163, stratum 2, offset -0.057223, delay 0.23943
server 120.88.47.10, stratum 2, offset -0.010830, delay 0.18791
server 113.30.137.34, stratum 3, offset 0.060199, delay 0.32492
12 Aug 01:20:44 ntpdate[82999]: adjust time server 120.88.46.10 offset -0.011305 sec

I would make the NTP server listen on localhost, both IPv4/IPv6 to make debugging easier:

Code:
listen on 127.0.0.1
listen on ::1

Now you can use ntpdate -q localhost to test your NTP server.
 
Many thanks for the reply and appreciate it very much

kpa said:
You can use ntpdate(8) without root privileges to test whether the NTP server responds and what the time adjustment would be if you use the -q (query) flag:

ntpdate(8) as normal user gives me
Code:
$ ntpdate -q 1.in.pool.ntp.org
server 123.108.225.6, stratum 0, offset 0.000000, delay 0.00000
server 123.108.200.163, stratum 0, offset 0.000000, delay 0.00000
server 120.88.47.10, stratum 0, offset 0.000000, delay 0.00000
server 120.88.46.10, stratum 0, offset 0.000000, delay 0.00000
12 Aug 09:19:07 ntpdate[4142]: no server suitable for synchronization found
kpa said:
I would make the NTP server listen on localhost, both IPv4/IPv6 to make debugging easier:

Code:
listen on 127.0.0.1
listen on ::1

Now you can use ntpdate -q localhost to test your NTP server.


I reinstalled openntpd and set the listen directives as suggested by you, a ntpdate -q localhost gives me the following
Code:
$ ntpdate -q localhost
server 127.0.0.1, stratum 16, offset 0.000001, delay 0.02563
server ::1, stratum 16, offset 0.000001, delay 0.02563
12 Aug 09:28:42 ntpdate[4477]: no server suitable for synchronization found
I do have the following msgs messages on console when I started up openntpd:
Code:
 ntpd: recvmsg 123.108.225.6: Connection refused
 ntpd: recvmsg 27.114.150.13: Connection refused
Thanks for taking time to reply but I am still not able to get this working, it's little frustrating you know as just a simple thing taking so much time to get it up and running.
Regards,
dotfish
 
It's showing a stratum of 16 and that means that the NTP service hasn't yet run long enough to be reliable. This is a peculiarity of net/openntpd that you don't see with the built-in ntpd(8). Let it run for a while and test again.
 
Hi @kpa,
Thanks for that suggestion, but the one you are talking is when ntpdate(8) querying the localhost which gives the stratum of 16, but if you look at the lines above it, where I am querying the 1.in.pool.ntp.org:
Code:
server 123.108.225.6, stratum 0, offset 0.000000, delay 0.00000
server 123.108.200.163, stratum 0, offset 0.000000, delay 0.00000
server 120.88.47.10, stratum 0, offset 0.000000, delay 0.00000
You could see it shows the stratum of 0 for those queries. So I am confused, correct me if I am wrong.

Thanks & regards
Dotfish
 
Last edited by a moderator:
Leave openntpd running for a while before querying it. It takes some time to get "synced".
 
@SirDice, thank you for the suggestion, I will stick by it and see how it goes

Regards
dotfish
 
Last edited by a moderator:
Hi,
Sorry couldn't keep my fingers away from this issue and I am checking out the tcpdump() because somewhere I came across the NTP may use a ICMP probe too, so ran a tcpdump and I got the following, like to know does it make sense that my ISP is blocking NTP?

Code:
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
09:58:14.822700 IP (tos 0x0, ttl 255, id 38713, offset 0, flags [none], proto ICMP (1), length 56)
    202.xxx.xxx.209 > 202.xxx.xxx.210: ICMP host 137.170.185.211 unreachable - admin prohibited filter, length 36
	IP (tos 0x0, ttl 63, id 65113, offset 0, flags [none], proto UDP (17), length 76)
    202.xxx.xxx.210.35697 > 137.170.185.211.ntp:  [|ntp]

The above capture 202.xxx.xxx.209 is my ISP gateway and 202.xxx.xxx.210 is my IP.
Hope all this now make sense.
Thanks & regards.
Dotfish
 
dotfish said:
somewhere I came across the NTP may use a ICMP probe too,
NTP doesn't use ICMP.

The reply you got simply means there's no NTP server running on 137.170.185.211. When an UDP packet is sent to a closed port the normal response would be an ICMP port unreachable.
 
Back
Top