In theory yes, but apparently it does not work for ntpd. That is what the maintainers of ntpd say in the following link:

http://support.ntp.org/bin/view/Supp...tion_PORTCHECK

Unless I missed it previously, WilliamS has not described his LAN hardware configuration. My guess is that he has a router between the ntpd box and the modem. If I were troubleshooting this problem, I would set the firewall on the ntpd box with port 123 open then connect said box directly to the WAN, i.e., plug it into the modem, and see if the problem goes away. If it does, then I would work backward from there in securing/networking the box.

My ISP's level 2 says nobody else has this problem, so no advice.

No LAN, no router, no firewall except iptables set by slackware installer.
ntp is only a client on my machine.

Its worth a try and adds some addition information.

That is selectable during the install process. It can be changed with timeconfig.


And your machine is plugged directly into the modem?
Does your modem have a built-in router? What is the make and model number?

Yes, plugged in directly.
No built-in router, according to xplornet tech support.

Sticker on the bottom says:
ViaSat
SURFBEAM 2 SATELLITE MODEM
MODEL NO: RM4100
30V 2.50A OR 55V 1.47A Made in Thailand

There's also a barcode sticker with RM4100N-043 on it.

Looks like it has the full complement, NAT, QoS, SPI, Filters.

http://www.viasat.com/files/assets/s...ew_018_web.pdf

Look on page 5 NETWORK DIAGRAM.
Under IDU 'Network Access Filters'.
Under 'ELEMENT MANAGEMENT' firewall control, NTP is specifically mentioned.

I wonder if they have blocked inbound 123 due to the
recent, and ongoing, NTP packet-amplification DDoS attacks?

https://www.us-cert.gov/ncas/alerts/TA14-013A

I thought you'd already got the time corrected!

In my default Slackware install ntp.conf has:

driftfile /etc/ntp/drift

No "conf" dir.

Another "guessing". I use the iburst option like specified in the default slackware ntp.conf, have you tried it?

After all the tries you did I don't think is a firewall problem but to be sure you could try openntpd that uses high numbered ports.

Couple of things.

• Continuously reinstalling either the operating system or NTP doesn't really accomplish much of anything.
• Applying all available updates immediately after installation (including the kernel updates on a 64-bit box) is a good first step. Be sure to copy the new /etc/ntp.conf.new file to /etc/ntp.conf.
• Not installing any additional software, no matter what it is, is a good third step; i.e., get the thing working first then start fiddling with it.
• In the case of NTP, if the default ".new" server configuration in /etc/ntp.conf, with the default server line uncommented (changing the line to server pool.ntp.org iburst) is used for initial installation, will, in almost every case, work.
• Not messing with anything else in /etc/ntp.conf is a good idea until it works; i.e., leave the damned thing alone except for the server pool.ntp.org iburst line.
• It's a good idea to initialize /etc/ntp/drift to zero (echo 0>/etc/ntp/drift; this will save NTP from going into special mode for up to an hour determining the system clock frequency and calculating the drift value -- it will start in normal mode instead of special mode. Roughly every hour, NTP will update /etc/ntp/drift until it has walked the system clock into synchronization.
• If the hardware clock is manually set (in the BIOS) to the correct UTC time before installation, that can save a lot of problems later (it can also be set to the correct local time if that is the preference). One or the other; keep it that way but UTC has become the preferred time for the hardware clock by upstream developers.
• Before starting up NTP, the system clock should be set with ntpd -d -g -q (preferred) or ntpdate XX.pool.ntp.org where XX is the 2-character country code where the machine lives. The first assumes that the server line in /etc/ntp.conf is as shown above.
• On start up, if NTP does not synchronize with an external server within roughly 5 minutes and there is no refid address shown in the display of ntpq -pn, the problem is not in the local machine: it will be in a router that does not pass port 123 UDP (not 123 TCP!) or that port is being blocked by the ISP (and you're beating a dead horse if it has been blocked at the ISP servers).
• Probably the only practical solution (if the ISP is blocking port 123 UDP) is periodically setting the time using ntpd [-d] -g -q ([-d] indicate that it's optional) with a suitable pool server in a cron job or a reference clock that connects via Ethernet to a router (from, say, a supplier like http://css-timemachines.com/). Reference clocks are not cheap but they are effective when used on a LAN with NTP.

Hope this helps some.

Thanks for the info.
I u sed it to get level 2 tech support to send my complaint to a higher power, he assured me that an answer would be forthcoming in 72 hours.

I corrected the time with ntpdate -u.
I was tired, drift file is in the right place.
Never tried iburst; until now never needed. Maybe after i hear from ISP.

you know I have used ntp for years in slackware it has never worked right. I have three installs all set the same way 1337 14.0 14.41.
I am smart enough to understand how it works. I understand the program well.
But it never has worked right FOR ME since 2004. it is hit and miss.
I do not really care I just do not care anymore. I reach up and move the dial by hand .
When you boot up it should read the time and set it it is that simple if it doesn't then it is broke. jiggle the handle.

When booting from one system to another it screws up everything. I do not care simple jiggle the handle.
set to local time boot read bios clock set it but never works that way jiggle the handle.

Like Drakeo says ntpd is problematic. Time ago I've played trying not generic servers, selecting specific servers combining different stratums and it gave me problems.

I had the same experience GazL describes with 'ntpd -g -q', ntpdate gave me a better result for correcting the time the first time.

On Crux I use openntpd that works without problems. That's why despite I agree with tronayne about not installing additional software it's not a bad idea giving openntpd a try.

All the above symptoms seem to be related with the same issue, the need of port 123 (and of course servers availability). The bad thing is that the Williams' ISP argument "nobody else has this problem" could mean they have no idea and/or interest in the matter.

And that's all what I can say.

I had the opposite experience, such that ntp always worked perfectly.
All I did was comment out the fudge lines, put the pool servers into /etc/ntp.conf and chmod +x the two rc.d scripts.

Same here...