NTP broken with 7.1?

Okay, so I killed the HTTP proxy and the SOCKS5 proxy and NTP started working again. No reboot, no nothing.

It looks like there is a fundamental problem with the packet processing (that interferes with other functions of the Astaro server) that for me is worse in 7.1 vs. 7.011.

Even a moderate load on Astaro will cause issues in other services. Also if the CPU spikes due to 'admin-reporter.' hogging one CPU to the tune of 90-100% then there are other problems. 

It is like Astaro is running a denial of service attack on itself [:S]

So the lesson here is to image the Astaro box before doing a firmware upgrade. For me, 7.1 is a downgrade.

Something does seem to be amiss with NTP or its interaction with the hardware clock. I have 2 older IBM 8310 PCs, one running SuSE 9 (with NTP running) and one with Astaro 7.1 (setup with an NTP source) and I have swapped the hardware between the 2 and the problem follows the Astaro. They are both setup to access the same external Internet NTP source.

The Astaro box kept semi-locking up, the Webadmin didn't want to load, you couldn't get a console login to work, I couldn't get a PPTP connection to complete but NAT functions allowing OWA access and email was passing through. I am not using the HTTP proxy, just the SMTP proxy. When I would restart the system and look at any reports there would be a large gap in time like the system had quit logging.

What I discovered was that the system was jumping back in time and I assume that NTP couldn't handle it. I have removed all NTP Server entries and the lockup problem is gone but last night the system jumped back 13 hours (I'm using US Eastern time if that helps solve the problem). Remember, this same hardware did not have the problem with the SuSE NTP so it has something to do with the Astaro. It may have something to do with the IBM 8310 and Astaro becvause I have other hardware that doesn not have the problem but I've tried BIOS updates with no change to the problem.

I also know that the system doesn't lose time, I check during the day, it jumps back by hours, the min. remain correct. I can't say it always happens at night but that is when I catch it because I won't have an Executive Report in the morning and when I connect to the system I discover it is because the system time hasn't reached the end of the previous day yet.

I hope all this deatil helps.

There are 3 pairs of NTP packets, all initiated by me hitting the "update now" button in WinXP.
Only the 3rd try actually succeeded on the PC.

One difference I see is that in the 3rd request on the return packet, the Originate Time Stamp is nearly identical to the Receive and Transmit Time Stamps. On the first two requests the Originate Time Stamp is ahead of the Receive/Transmit Time Stamps by two seconds.

So looking at the 3rd request packet, it appears that the clock on the client had already been updated by the 2nd NTP request, judging by the Reference Clock Update Time field in the 3rd request.

Will have to do some research on the NTP protocol, but I don't see any reason why the Windows NTP client wouldn't have synchronized each time.

As far as running an NTP server on Windows... the PCI-CISP standards require a central NTP server on the internal network, and (I believe) it needs to be on a separate machine from the webserver, etc.

Remember that the NTP daemon doesn't actually have to do any serving - you can use it as a client to maintain contact with your NTP servers.

The NTP daemon is much more effective at keeping the local clock in sync because it can slowly tweak the local clock if the clock is only slightly out of sync from the upstream NTP servers. It also accounts for network jitter and delay meaning it is very effective at synchronizing to distant servers (though closer is obviously better). It can also calculate a clock drift value to determine what direction the local clock naturally drifts - then use this value to constantly slightly tweak the local clock to keep it in sync without having to resort to periodic time resets.

This means you can still use Astaro as the NTP server, you then install the Windows NTP daemon and configure it to synchronize to Astaro. Disable Window's built in NTP synchronization since NTP will be doing it for you.

Hi,

I join this tread as i notice that my Astaro clock is not correct. I set NTP server to 0.be.pool.ntp.org (as i'm in belgium) but it seems Astaro doesn't sync... And as BarryG said, I don't find any NTP log on the Astaro.

I'm running version 7.104.

Acutally my configuration is, that my Domain Controllers are syncing with the astaro. I regularly see events in the eventlog:

The time provider NtpClient cannot reach or is currently receiving invalid time data from ASG 

 

After disable/enable the NTP Server on the Astaro my Windows 2k3 servers are syncing correctly afterwards..

On my side, i keep having problems with NTP on the Astaro. NTP is configure to sync with O.be.pool.ntp.org, but i have to adjust time manually quite ofen. I did it today as the astaro was 10 minuts to late... I don't understand how it's possible! 
Or the sync doesn't work and the system clock is quite buggy, or the sync is working but the ntp.org time is not correct...

Any idea???

We have the same issues, with NTP on astaro only working one time when you hit apply in ntp settings. After a week it may happen that Astaro is 10 minutes late. We're using our own time server to synchronise (dcf-77 atom time) so it's not the time server to blame here. I noticed these problems with the initial release of V7. Also created a bug report. Astaro Support told me that it's a bug in the latest linux NTP client package, so they can't do anything until the maintainers of that ntp package fix the problem.

Astaro Support told me that it's a bug in the latest linux NTP client package, so they can't do anything until the maintainers of that ntp package fix the problem.

See if you can't get them to reference that bug upstream.

I've got dozens of Linux boxes here all running NTP without any issue at all - they all stay well within a second of each other.

I'm not sure what bug Astaro may be running in to, but it should be easily solved by moving to a different version. The fact that they also only let you sync to one NTP server does not help - you really should be using at least two - possibly three or four.

Syncing to a single random NTP server will generally not be very reliable unless your connection to is also very reliable - and when you're pulling a random NTP server out of a hat (using pool.ntp.org) that is not very likely.

Hi there, 

this is interresting. 

MSchenk, can you please send me a note who from astaro support told you that information about a bug in the NTP client package, as i don't find an entry in our bugtracking system and hardly believe that is an issue there. thx

We actually do have a shortcomming, which is that we only select a single ip from the hostname pool and sync against this one. 
i'll check if this can be improved. 

thanks
Gert

We actually do have a shortcomming, which is that we only select a single ip from the hostname pool and sync against this one. 
i'll check if this can be improved. 

If we could define at least two NTP servers and preferably up to four that would be great. Thanks Gert!

Here's the support Case concerning this issue: (GERMAN)


Case #00055117: astaro time sync funktioniert nicht richtig

--------------------------------------------------------------------------------

Case Details

--------------------------------------------------------------------------------

Status: Issue resolved

Company:  
Type: Issue 
Reason: Not an Astaro Issue 
Opened: 16 Oct 2007 
Closed: 26 Oct 2007 
License: ASL7 250 
Product: Astaro Security Gateway Software 
Software Version: 7.009 
Support Level: silver 
Category: Hardware 
Priority: Medium 
Description: Wenn wir unter "Management - System Settings - Time and Date - Synchronize time with internet server" einen NTP Server eintragen (Lokaler Server mit DCF77 Uhr) dann funktioniert auch die Zeitsynchronisation erst, aber trotzdem ist nach ca. 2 Wochen die Zeit 15 min hinterher. Geht man wieder in die Einstellungen und klickt "apply" dann wird wieder die "richtige" Uhrzeit aktiv. Dieses sollte aber automatisch funktionieren? 
 
---

See "Support case Closed" plus the reason "Not an Astaro Issue"

This is what i got from the astaro tech support as mail response:

->

Guten Tag Herr Schenk,

Ich habe neue Informationen zu diesem Problem. Leider muss ich ihnen mitteilen, dass sich dieses Problem im Moment nicht beheben lässt. Ursache ist, dass dies ein Fehler in der eingesetzten NTP Version ist.

Leider müssen wir hier abwarten, bis dieser Fehler durch den Maintainer von ntp gefixt ist.


Mit freundlichen Grüssen

Nils Schiele  | Support Engineer Astaro AG | www.astaro.de | Phone +49-721-25516-0 | Fax +49-721-25516-200 | Amalienbadstrasse 36 / Bau 33a | 76227 Karlsruhe | Germany

Download your free 30 day trial version of the award-winning Astaro Security Gateway solution here: https://my.astaro.com/download/

------

Translated to english this states exactly what i wrote in one of the above posts.

My NTP server in ASL 7.104 is 2 minutes off, both on the firewall itself, and all the PCs syncing to it.

I ran PS, and ntpd is running.

There is nothing in the logs about ntp, and nothing with port 123 in the packetfilter log.

I have the firewall set to use the "NTP server pool".

Barry

My NTP server in ASL 7.104 is 2 minutes off, both on the firewall itself, and all the PCs syncing to it.

I ran PS, and ntpd is running.

There is nothing in the logs about ntp, and nothing with port 123 in the packetfilter log.

I have the firewall set to use the "NTP server pool".

Barry

If you log in to the console or ssh as root and run "ntpq -p", what does the output look like?

It's probably one of two things:

1. The time server you happened to get from the pool is not actually running.
2. The time of your server's time was too different than the time on the pool and ntp won't sync up.

#1 would be fixed if you could specify multiple NTP servers to sync to.
#2 should be fixable by adding -g to the startup option to ntpd.

Edit:

I just checked one of my v7 servers and it's not good.

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*127.127.1.0     .LOCL.          10 l   59  128  377    0.000    0.000   0.004

 12.110.191.46   64.202.112.75    2 u 296m   9h  377   80.971  54559.0 2381.82

For some reason ntpd is preferring the local clock even when the server it is supposed to be syncing to is of a much lower stratum.

Time has drifted 55 seconds off the reference clock as well.

I'll have to go dig into the logs to see what I can find...

OK, in the logs I am seeing ntpd errors:

"kernel time sync error 0001"

A quick google of the phrase shows that it's a bug in the Linux kernel. The result of the bug is that time starts falling out of sync.

I don't think that my earlier two suggestions will fix this problem. The kernel needs to be patched.

This could be fixed in the beta release - anyone check?

I don't have those errors, but I do have a similar (worse) output from ntpq:

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*LOCAL(0)        .LOCL.          10 l   82  128  377    0.000    0.000   0.002

 gallifrey.chpc. 209.132.176.4    2 u  41m   9h  377   71.834  -122985 1392.08



fw:/var/log # grep -i "kernel time" *.log

(no output)

Barry

Yep, your ntp daemon is preferring the local clock vs the ntp server as well. I wonder why...

I have not used the ntpd in Astaro, but have been running chrony on a small 300Mhz P2 for years now.  I point all my equipment to it, Cisco, MS AD, other appliances and it just seems to work.  

I would definitely recommend chrony in case you wanted to try something different, has a nice control app - chronyc which lets you see the clients that requested time from it and a verbose status of the time sync.

One strange thing I noticed was that the packet filter was dropping packets from the external interface of the firewall to the NTP server on occasion. I added a packet filter rule which got rid of the packet filter drops, but it still won't sync up. I'm assuming that it's not because of the huge amount of jitter that ntpd is reporting.

I've checked other NTP servers and they all report jitter in the single digits where Astaro is reporting thousands.

Has anyone tested the beta?

i have these logs in the kernel log:

2008:06:30-12:39:52 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:39:53 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:39:54 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:39:55 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:39:56 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:39:57 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:39:58 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:39:59 (none) kernel: set_rtc_mmss: can't update from 59 to 9
2008:06:30-12:49:34 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:34 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:35 (none) kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
2008:06:30-12:49:35 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:35 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:35 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:35 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:35 (none) kernel: eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
2008:06:30-12:49:35 (none) kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
2008:06:30-12:49:55 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:49:03 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:03 (none) kernel: device eth0 entered promiscuous mode
2008:06:30-12:49:03 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:49:03 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:49:03 (none) kernel: device eth0 entered promiscuous mode
2008:06:30-12:49:30 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:49:52 (none) kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
2008:06:30-12:49:52 (none) kernel: eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
2008:06:30-12:49:52 (none) kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
2008:06:30-12:50:06 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:50:06 (none) kernel: device eth0 entered promiscuous mode
2008:06:30-12:50:06 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:50:06 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:50:06 (none) kernel: device eth0 entered promiscuous mode
2008:06:30-12:50:24 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:53:26 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:53:26 (none) kernel: device eth0 entered promiscuous mode
2008:06:30-12:53:26 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:53:26 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:53:26 (none) kernel: device eth0 entered promiscuous mode
2008:06:30-12:54:03 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:54:22 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:54:22 (none) kernel: device eth0 entered promiscuous mode
2008:06:30-12:54:22 (none) kernel: device eth0 left promiscuous mode
2008:06:30-12:54:22 (none) kernel: eth0: Promiscuous mode enabled.
2008:06:30-12:54:22 (none) kernel: device eth0 entered promiscuous mode


and this:

***x:/root # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l    7  128  377    0.000    0.000   0.001
 ntp0.nl.uu.net  .GPS.            1 u 1079 2048  377   52.201  -899641 299873.
***x:/root #

when i set the time correct the whole box freezes and cpu goes to 100%. all traffic stops and webadmin just times out.

***x:/root # tail -f /var/log/system.log

2008:06:30-14:47:17 (none) ntpd[13200]: ntpd exiting on signal 15
2008:06:30-14:47:18 (none) ntpd[14921]: ntpd 4.2.4@1.1437-o Wed Apr 18 07:34:56 UTC 2007 (1)
2008:06:30-14:47:18 (none) ntpd[14922]: precision = 1.000 usec
2008:06:30-14:47:18 (none) ntpd[14922]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
2008:06:30-14:47:18 (none) ntpd[14922]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
2008:06:30-14:47:18 (none) ntpd[14922]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
2008:06:30-14:47:18 (none) ntpd[14922]: Listening on interface #2 eth0, ***.17.x.1#123 Enabled
2008:06:30-14:47:18 (none) ntpd[14922]: Listening on interface #3 eth1, xx.xx.***.141#123 Enabled
2008:06:30-14:47:18 (none) ntpd[14922]: Listening on interface #4 eth2, ***.27.x.1#123 Enabled
2008:06:30-14:47:18 (none) ntpd[14922]: kernel time sync status 0040
2008:06:30-14:47:18 (none) ntpd[14922]: frequency initialized -284.866 PPM from /var/ntp.drift
2008:06:30-14:47:29 (none) ntpd[14922]: synchronized to 193.67.79.202, stratum 1
2008:06:30-14:22:29 (none) ntpd[14922]: time reset -1499.396621 s
2008:06:30-14:22:29 (none) ntpd[14922]: kernel time sync status change 0001
2008:06:30-14:22:46 (none) syslog-ng[2540]: SIGHUP received, restarting syslog-ng
2008:06:30-14:22:47 (none) syslog-ng[2540]: new configuration initialized
2008:06:30-14:22:49 (none) syslog-ng[2540]: SIGHUP received, restarting syslog-ng
2008:06:30-14:22:50 (none) syslog-ng[2540]: new configuration initialized
2008:06:30-14:22:53 (none) sysmond[11583]: received TERM signal
2008:06:30-14:22:53 (none) sysmond[11583]: terminating.
2008:06:30-14:22:54 (none) sysmond[15325]: sysmond 1.16 starting
2008:06:30-14:22:54 (none) sysmond[15325]: daemonizing
2008:06:30-14:22:54 (none) snmpd[15352]: NET-SNMP version 5.3.0.1
2008:06:30-14:22:55 (none) snmpd[15352]: Received TERM or STOP signal...  shutting down...
2008:06:30-14:23:01 (none) snmpd[15443]: NET-SNMP version 5.3.0.1
2008:06:30-14:23:01 (none) /usr/sbin/cron[10905]: (*system*) RELOAD (/etc/crontab)
2008:06:30-14:23:05 (none) syslog-ng[2540]: SIGHUP received, restarting syslog-ng
2008:06:30-14:23:05 (none) ntpd[14922]: ntpd exiting on signal 15
2008:06:30-14:23:06 (none) syslog-ng[2540]: new configuration initialized
2008:06:30-14:23:12 (none) ntpd[15746]: ntpd 4.2.4@1.1437-o Wed Apr 18 07:34:56 UTC 2007 (1)
2008:06:30-14:23:12 (none) ntpd[15747]: precision = 1.000 usec
2008:06:30-14:23:12 (none) ntpd[15747]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
2008:06:30-14:23:12 (none) ntpd[15747]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
2008:06:30-14:23:12 (none) ntpd[15747]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
2008:06:30-14:23:12 (none) ntpd[15747]: Listening on interface #2 eth0, ***.17.x.1#123 Enabled
2008:06:30-14:23:12 (none) ntpd[15747]: Listening on interface #3 eth1, xx.xx.***.141#123 Enabled
2008:06:30-14:23:12 (none) ntpd[15747]: Listening on interface #4 eth2, ***.27.x.1#123 Enabled
2008:06:30-14:23:12 (none) ntpd[15747]: kernel time sync status 0040
2008:06:30-14:23:12 (none) ntpd[15747]: frequency initialized -284.866 PPM from /var/ntp.drift
2008:06:30-14:23:13 (none) syslog-ng[2540]: SIGHUP received, restarting syslog-ng
2008:06:30-14:23:14 (none) syslog-ng[2540]: new configuration initialized
2008:06:30-14:23:14 (none) syslog-ng[2540]: io.c: do_write: write() failed (errno 32), Broken pipe
2008:06:30-14:23:14 (none) syslog-ng[2540]: pkt_buffer:[:D]o_flush(): Error flushing data
2008:06:30-14:23:23 (none) syslog-ng[2540]: SIGHUP received, restarting syslog-ng
2008:06:30-14:23:24 (none) syslog-ng[2540]: new configuration initialized
2008:06:30-14:23:54 (none) syslog-ng[2540]: SIGHUP received, restarting syslog-ng
2008:06:30-14:23:55 (none) syslog-ng[2540]: new configuration initialized
2008:06:30-14:24:01 (none) /usr/sbin/cron[10905]: (*system*) RELOAD (/etc/crontab)
2008:06:30-14:24:23 (none) syslog-ng[2540]: SIGHUP received, restarting syslog-ng
2008:06:30-14:24:24 (none) syslog-ng[2540]: new configuration initialized
2008:06:30-14:24:31 (none) ntpd[15747]: ntpd exiting on signal 15
2008:06:30-14:24:33 (none) ntpd[16841]: ntpd 4.2.4@1.1437-o Wed Apr 18 07:34:56 UTC 2007 (1)
2008:06:30-14:24:33 (none) ntpd[16842]: precision = 1.000 usec
2008:06:30-14:24:33 (none) ntpd[16842]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
2008:06:30-14:24:33 (none) ntpd[16842]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
2008:06:30-14:24:33 (none) ntpd[16842]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
2008:06:30-14:24:33 (none) ntpd[16842]: Listening on interface #2 eth0, ***.17.x.1#123 Enabled
2008:06:30-14:24:33 (none) ntpd[16842]: Listening on interface #3 eth1, xx.xx.***.141#123 Enabled
2008:06:30-14:24:33 (none) ntpd[16842]: Listening on interface #4 eth2, ***.27.x.1#123 Enabled
2008:06:30-14:24:33 (none) ntpd[16842]: kernel time sync status 0040
2008:06:30-14:24:33 (none) ntpd[16842]: frequency initialized -284.866 PPM from /var/ntp.drift
2008:06:30-14:25:01 (none) /usr/sbin/cron[16884]: (root) CMD (   /usr/local/bin/reportcontrol.sh)
2008:06:30-14:25:01 (none) /usr/sbin/cron[10905]: (*system*) RELOAD (/etc/crontab)

now i get this in the kernel.log

2008:06:30-15:36:40 (none) ntpd[16842]: synchronized to 193.67.79.202, stratum 1
2008:06:30-15:40:01 (none) /usr/sbin/cron[18615]: (root) CMD (   /usr/local/bin/reportcontrol.sh)
2008:06:30-15:45:57 (none) /usr/sbin/cron[18639]: (root) CMD (   /usr/local/bin/reportcontrol.sh)
2008:06:30-15:45:57 (none) /usr/sbin/cron[18643]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.pl)
2008:06:30-15:45:57 (none) /usr/sbin/cron[18647]: (root) CMD (nice -n19 /usr/local/bin/create_rrd_graphs.plx)
2008:06:30-15:46:01 (none) /usr/sbin/cron[18668]: (root) CMD (/sbin/auisys.plx --nosys)
2008:06:30-15:48:15 (none) daemon-watcher[3161]: Watching selfmonng.plx - running fine
2008:06:30-15:49:01 (none) /usr/sbin/cron[18701]: (root) CMD (/sbin/audld.plx)
2008:06:30-15:50:01 (none) /usr/sbin/cron[18713]: (root) CMD (   /usr/local/bin/reportcontrol.sh)
2008:06:30-15:55:01 (none) /usr/sbin/cron[18764]: (root) CMD (   /usr/local/bin/reportcontrol.sh)
2008:06:30-15:58:01 (none) /usr/sbin/cron[18805]: (root) CMD (test -x /usr/local/bin/snort-cleanup && /usr/local/bin/snort-cleanup)
2008:06:30-15:58:38 (none) ntpd[16842]: synchronized to LOCAL(0), stratum 10
2008:06:30-15:58:49 (none) ntpd[16842]: kernel time sync error 0009
2008:06:30-16:00:01 (none) /usr/sbin/cron[18835]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.pl)

I'm not sure what the errors mean, but how far off is your clock getting?

The problem I have is that the clock is fine on Astaro, but the PCs in the LAN won't sync with it most of the time.
I haven't had the PCs on much lately though, so I'm not sure if it's better in 7.2

Barry