adjust time: sntp works, but ntpd does not?
 

Dear all,
I want to synchronise the system time at boot from the local time servers.
sntp works OK:
The above command adjust the time successfulle within a few seconds.
However, the command:
,
which should actually do the same, hangs and never releases the console.
Any clues?

Best regards,
Martin

Just off the cuff (and x-ing my fingers hoping its right), one is a daemon (ntpd) and the other is not. You might have to background the daemon with a '&' at the end of your command ...
ntpdate (if it still exists) will do the same as sntp

Hi. Can't repro - works here. Can you provide a bit more info:

1. ntp version
   
2. pastebin of ntpd.trace generated by:
   
   Code:

   ---

   strace -o ntpd.trace /usr/sbin/ntpd -gqc /dev/null bg.pool.ntp.org

   ---

--mancha

Dear mancha,
thank You very much for Your reply.
This is the output strace:
And here is the ntpd version:
Best regards,
Martin

Hi Martin.

The strace output I want to see should be in a newly-created file called ntpd.trace in the directory where you ran the command.

Because it hangs, let the strace command run for 10 seconds or so before exiting to let the trace file fill up with relevant info.

It might be a long file, so rather than paste the contents here directly, use an online bin (e.g. dpaste).

--mancha

Hello, Mancha,

Thank You for Your reply. The contents of the ntpd.trace file is viewable from:

https://dpaste.de/2xeT

Best regards,

Martin

Hi Martin.

That trace helped a lot. We're indeed not getting a response on the socket (no recvmsg after the sendto on line 422).

Can we look at network traffic while you make the ntp request? For that, open up two terminals.

In terminal #1 run:

Once that's running, in terminal #2 run:

In addition to the tcpdump output from above, can you please provide output from:

--mancha

Dear Mancha,

Thank You very much for Your helpfulness. Here is the output of the commands in the order You suggested them:


Best regards,
Martin

Hi - thanks for the output.

My hunch was correct, your firewall is blocking the reply.

The reason sntp is working for you is because it uses random high ports. On the other hand, ntpd uses a low port (port 123 locally)
and your firewall blocks incoming packets to low ports (1023 and lower).

Now, though UDP is technically stateless, Linux's netfilter connection tracking system is clever and has ways of determining if an
incoming UDP datagram is part of an existing connection you previously established.

So, a possible solution for your issue is to permit incoming packets on the ppp0 interface that are part of an existing connection
(i.e. replies) while still blocking new incoming connections to ports 1-1023. This can be achieved by inserting the rule in red:

Note: order is important so make sure you insert the rule where I placed it (i.e. as rule #3).

--mancha

PS If you want to only allow established/related packets in to UDP/123 (which is all you will need for ntpd to work as you want it),
you can use this more restrictive rule instead:

Dear Mancha,

Thank You very much for Your helpfulness and collaboration. I just corrected the firewall-standalone file
in the ppp directory and now ntpd -gq works. Thank You very much!

Best regards,
Martin

You're welcome Martin - glad you've got it working.

An ancillary benefit is others who've been reading this thread might have learned a thing or two from our exchange.

--mancha