SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Well, the GRC port scanner only checks tcp connections, so that is not a definitive test, but if you are dropping tcp connections on port 123 there is a good chance you are dropping udp as well. The ntptrace result supports that as possibility. Your ISP may be dropping 123, or your network could be.
You could check /etc/services for udp on port 123. Check your sys logs for information, ntpd does log messages there. Start ntpd from the command line with the -d (debug) option.
Have you tried rebooting your modem, router, and any other network nodes?
That grc.com looks for the external IP. It's probably reporting about ports on the ISP machine.
It scans the IP you contact it with, which will be his modem's WAN IP.
Originally Posted by WilliamS
I always set shorewall to stealth all the incoming ports. AFAIK that's what a firewall is for.
Sure, if you don't want ntpd to work.
Are you using a NAT router, and/or is one built into your modem? If yes, you will need to forward port 123 the machine you are running ntpd on. ntpd has no port configuration and requires unrestricted access to port 123 in both directions.
ntpdate can use unrestricted ports, that is why it works for you.
I believe Chrony and OpenNTPD are configurable to use unrestricted ports (above 1024), you could go that way also.
Google "+NAT +NTP", and you will find other people having the same problem you are.
Are you using a NAT router, and/or is one built into your modem? If yes, you will need to forward port 123 the machine you are running ntpd on.
As a general statement I disagree. Typically since the ntp traffic is outgoing first the router's firewall should "label" it as an established connection. However, like you stated there are others with similar problems. In an earlier post the OP ran ntpdate with the -d option which seemed to worked but uses an unprivileged port but does not update the system clock which is why the difference was still ~8 seconds. Have you tried just running:
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
You need to do NTP stuff as root (or su -). In console, you can log in as root (and be really careful); if X is running and you use a terminal, make sure you're using a log in terminal (so you don't have just a $ prompt). You can "source" a non log in terminal:
# . /etc/profile
ls -al /etc/ntp.conf /etc/rc.d/rc.ntpd /etc/ntp
-rw-r--r-- 1 root root 2613 May 1 11:25 /etc/ntp.conf
-rwxr-xr-x 1 root root 1481 Feb 13 17:45 /etc/rc.d/rc.ntpd*
drwxr-xr-x 2 root root 4096 May 5 11:40 ./
drwxr-xr-x 102 root root 12288 May 3 11:27 ../
-rw-r--r-- 1 root root 8 May 5 11:40 drift
-rw------- 1 root root 22 Feb 13 17:45 ntp.keys
-rw-r--r-- 1 root root 0 Feb 13 17:45 step-tickers