[ntp:questions] Need help on NTP client

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Tue Jul 28 04:48:25 UTC 2015


Hi Gao,
I have not seen any output from commands like these posted.
What are the results from the preceding working traceroute command, the failing traceroute command, and the subsequent ntpdate commands?

Do not expect NTP responses from traceroute commands, they only hit the network layer, not the NTP server, and are intended only to identify possible network filtering, when compared to the preceding working generic traceroute.

Similarly, the unprivileged port ntpdate command output compared to the privileged port ntpdate command output may show where the network is being filtered.

It may be that all NTP traffic from that client is going via your router which may block it, or it could be a switch rule.

Check the routes on your working and non-working clients with netstat -r, and change the non-working client if different.
Check your IP addresses are unique by doing nslookup by name and address, to ensure they map both ways to the same host:
I have seen cloned systems using the same static IP address, which really messes up traffic delivery!
-- 
Take care. Thanks, Brian Inglis

On 2015-07-27 18:13, Gao wrote:
> If you read my previous email you see all these tests you recommended works, except this one:
>    traceroute -U -p 123 $other
>
> I think the reason is the server side don't response/echo back for UDP.
>
> But when I running this command on the CentOS7, I also running tcpdump at the server end amd it DOES received lot packets on port 123:
>
> [root at ovpn ~]# tcpdump -s0 port 123 and host 192.168.123.22
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>
> 17:09:40.978465 IP 192.168.123.22.54055 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
> 17:09:40.978495 IP 192.168.123.22.59641 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
> 17:09:40.978503 IP 192.168.123.22.37803 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
> 17:09:40.978513 IP 192.168.123.22.47468 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
> 17:09:40.978519 IP 192.168.123.22.39741 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
> 17:09:40.978525 IP 192.168.123.22.44615 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
> 17:09:40.978531 IP 192.168.123.22.59443 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
> 17:09:40.978566 IP 192.168.123.22.44037 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32
>
> I think this proves that the port 123 on server received packets from client. So the question is why the ntpd's NTP request to the server is lost somewhere, although tcpdump shows it sent out NTP request?

> On 15-07-27 04:17 PM, Brian Inglis wrote:
>> Hi,
>> Check from each end to the other that:
>>     nslookup $other
>>     ping -c 5 $other
>>     traceroute $other
>>     traceroute -U -p 123 $other
>>     ntpdate -qu $other
>>     ntpdate -q $other
>> all work - any failure compared to the previous result should point you to the source of the problem.



More information about the questions mailing list