NTP Problems and questions
-
First of all I'm curious, what is the difference between "prefer" and "noselect" in the NTP options? What would they be used for?
Second, I have a SuperMicro server and the IPMI is NTP capable but I can't get it to sync. If I set the NTP to a outside server it'll sync just fine but it won't sync with PfSense. I've tried the IP, DNS, tried changing some of the NTP configurations listed at the bottom of the NTP service page and nothing will make the IPMI happy.
I keep getting the error, "Temporary failure in synchronizing with NTP Server!"I've sniffed the packets and PfSense is responding and saying, "Hey, your out of sync" and sending information but the IPMI isn't happy with what it's receiving from what I can see.
Here's a small capture, IPs removed…...
01:03:43.227759 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has xxx.xxx.xxx.xx2 tell xxx.xxx.xxx.xx8, length 46
01:03:43.670639 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 76)
xxx.xxx.xxx.xx2.123 > xxx.xxx.xxx.xx1.123: NTPv4, length 48
Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 4 (16s), precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3376598400.259312003 (2006/12/31 16:00:00)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3376598400.259312003 (2006/12/31 16:00:00)
01:03:43.670830 IP (tos 0xb8, ttl 64, id 33050, offset 0, flags [none], proto UDP (17), length 76)
xxx.xxx.xxx.xx1.123 > xxx.xxx.xxx.xx2.123: NTPv4, length 48
Server, Leap indicator: (0), Stratum 3 (secondary reference), poll 4 (16s), precision -19
Root Delay: 0.096191, Root dispersion: 0.043426, Reference-ID: xxx.xxx.xxx.externalIP
Reference Timestamp: 3656826190.298544853 (2015/11/18 01:03:10)
Originator Timestamp: 3376598400.259312003 (2006/12/31 16:00:00)
Receive Timestamp: 3656826223.670658707 (2015/11/18 01:03:43)
Transmit Timestamp: 3656826223.670777022 (2015/11/18 01:03:43)
Originator - Receive Timestamp: +280227823.411346703
Originator - Transmit Timestamp: +280227823.411465048 -
First of all I'm curious, what is the difference between "prefer" and "noselect" in the NTP options? What would they be used for?
It'd perhaps help to read what's written in the GUI?!
The prefer option indicates that NTP should favor the use of this server more than all others.
The noselect option indicates that NTP should not use this server for time, but stats for this server will be collected and displayed.No, not kidding you. It's written there:
As for your IPMI, beyond getting a fixed firmware with non-broken NTP client, good luck.
-
(2006/12/31 16:00:00)
I would suggest manually setting the clock to be close, and then let it sync.. Normally a NTP client will not sync if time it gets back is WAY out of wack… Which clearly yours is.
"If I set the NTP to a outside server it'll sync just fine but it won't sync with PfSense"
You say it syncs to outside??? Then why are you showing time in 2006?? If you were syncing to outside and then changing to pfsense you would think you time would be closer ;)btw do you know what version of ntp your ipmi is using? If time is 2006 its prob really really OLD ;)
-
First of all I'm curious, what is the difference between "prefer" and "noselect" in the NTP options? What would they be used for?
It'd perhaps help to read what's written in the GUI?!
The prefer option indicates that NTP should favor the use of this server more than all others.
The noselect option indicates that NTP should not use this server for time, but stats for this server will be collected and displayed.No, not kidding you. It's written there:
As for your IPMI, beyond getting a fixed firmware with non-broken NTP client, good luck.
Crap, well I over looked that on the page, thanks for pointing that out.
-
(2006/12/31 16:00:00)
I would suggest manually setting the clock to be close, and then let it sync.. Normally a NTP client will not sync if time it gets back is WAY out of wack… Which clearly yours is.
You say it syncs to outside??? Then why are you showing time in 2006?? If you were syncing to outside and then changing to pfsense you would think you time would be closer ;)
btw do you know what version of ntp your ipmi is using? If time is 2006 its prob really really OLD ;)
That was my thought too. I set the clock then change it back to sync via NTP and the clock reverts back to factory defaults. So I've tried that.
When I say outside, I mean like pool.ntp.org
If set to a outside server it syncs successfully.I don't know what version the NTP is yet. I've also been emailing SuperMicro Technical support in hopes of trying to get it working. The IPMI is 3.4
-
Well I am really curious what the actual ntp config is.. A search for supermicro ntp finds a issue with fixing the old ntp being used for ddos, looks like 313 for the code - you say your on 3.4 so what is your specific board. Would like to download the firmware to check the config for ntp they have in there, and possible what version of ntp is included. You can tell its v4 in your sniff… But there are lots of different versions of v4.. current is 4.2.8p4 -- but I have been running dev versions 4.3 for quite some time..
https://www.supermicro.com/support/bios/firmware0.aspx
If you state what board you have can download the specific firmware and take a look see.
-
Sounds like a dead CMOS battery to me in the first place.
-
yeah thats a valid point, it seems odd that it would reset to 2006 date after it had synced just because you restarted ntp to point it to a different server..
-
Holy crap! It must be a bug!
I just checked the battery voltage from the IPMI and it's reading 3.24v
The motherboard is the X8TH-iF
So I just got it working. I had the NTP set to 0.pool.ntp.org and it was syncing. I just for the heck of it changed it to my firewall and it was successful for the first time.
So here is my thought….
The IPMI wouldn't sync because the date was to far out of range. Setting it manually then trying to change it back to NTP locally just reset the clock and made it try to set the time via NTP.
Setting it to a external NTP (for some reason) allowed it to sync the clock. Once synced for a while then changing the NTP to my local address without turning the service off kept the time without resetting back to the factory default time.Why it's doing this? I have no idea, but it's stupid and annoying!
Oh, and have to correct my IPMI version, it's 3.04
Firmware Revision : 3.04
Firmware Build Time : Dec 23 2014 19:33:27 -
Well I take it back, I just checked back and it errored again
 -
Same issue here. SuperMicro IPMI can no longer sync with the pfSense ntp server. Tried from two SuperMicro servers with different firmware/motherboards.
Works fine syncing to 0.pool.ntp.org though! (had to reboot the IPMI interface to get it to work with this server).
Something must have changed with the pfSense ntp server because it used to work fine with IPMI. Not sure when or what change would have affected things though.
Linux servers have no problem syncing with pfSense NTP, only the IPMI management interface has a problem.
-
I had a SuperMicro tech look into it. He couldn't sync either. I finally had to just sync to another server on my network that was syncing to PfSense.
-
Please see these threads:
https://forum.pfsense.org/index.php?topic=104710.0 and
https://forum.pfsense.org/index.php?topic=91781.0Newer versions of ntpd on FreeBSD have a problem with older versions of ntpdate (like what's built into your IPMI). Try turning off KOD packets in access restrictions, as detailed here:
https://forum.pfsense.org/index.php?topic=104710.msg584433#msg584433 -
To follow up, a couple of the SuperMicro servers which use a different IPMI interface sync fine to the pfSense IP address.
These servers are likely using a different IPMI chip and firmware.So problem appears related to one or more of SuperMicro's IPMIs.
I'll try the KOD modification suggestion described above, thanks!
-
Worked for me! ;D