SG-1100 incorrect date and time
-
Hello -
I'm fairly new to pfSense and only recently received my sg-1100. So far everything has been working great with the exception of the system showing the incorrect date and time. For example, right now it is June 29 2019 20:55 for me, but the system datetime shows May 19 2019 15:19. So far I have tried:
- Using different NTP servers (in the end went back to default as there as no difference)
- Changing / updating the timezones (correct for me is America/Chicago)
I have rebooted after updating NTP settings, as well. I haven't had success googling / finding forum topics / reading documentation on this specific issue, other than one edge case where somone's datetime was off by 6 years. Their issue was a low CMOS battery, and I cant imagine that would be my issue with a board that is less than a month old.
I am unsure where to go from here to resolve the issue, any help would be appreciated. I have the sense there may be something I need to do in the BIOS, but I am not positive and do now know how I'd accomplish this. I can provide whatever additional information / output is needed and am happy to read documentation myself if its spelled out somewhere and I just missed it. Many thanks in advance.
-
Sure you checked Current date/time and not built on ?
I can't check myself atm for the SG-1100 because mine is in the office and I'm at home.
2.4.4-p3 amd64 CE is built on Wed May 15 18:53:44 EDT 2019 ;-)-Rico
-
Fair question. I'm looking at the Current date/time on the System Information widget on my dashboard.
-
Whats is Status > NTP showing?
-Rico
-
Sorry, typing this out on mobile so I can't just post a screenshot.
Status - pool placeholder
Server - 0.pfsense.pool.
Ref id - .POOL.
Stratum - 16
Type - p
When - -
Poll - 64
Reach/delay/offset/jitter - all have value of 0Thanks!
Alex -
The server should probably be: 0.pfsense.pool.ntp.org
-
The server pool will always show zeros there but you should see a list of servers below that with real stats:
[2.4.4-RELEASE][root@1100.stevew.lan]/root: ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 +51.89.151.183 212.83.158.83 3 u 21 64 377 5.929 0.574 2.234 +178.62.16.103 195.66.241.2 2 u 133 64 374 6.727 0.428 0.250 -129.250.35.250 249.224.99.213 2 u 140 64 144 5.944 0.618 2.510 +134.0.16.1 195.66.241.2 2 u 127 256 377 6.569 0.400 0.494 -212.110.158.29 89.109.251.21 2 u 36 128 375 82.876 2.610 3.562 -213.199.225.30 212.160.106.226 2 u 117 128 361 37.243 1.190 0.318 -193.219.61.120 .MRS. 1 u 239 128 376 45.356 -3.015 0.319 -195.154.223.198 193.11.166.36 2 u 103 128 363 17.216 2.754 0.675 *194.80.204.184 .GPS. 1 u 56 64 377 16.168 0.387 0.261At least some of those should show reach 377 after some minutes. Otherwise you have a connectivity issue.
Steve
-
Just got back home and was able to grab some screenshots that should (hopefully) clarify my current setup:
System Information widget showing (incorrect) date/time:
Systems > General > Localization:
NTP Status:
NTP Server Config:
If I'm missing something key here to post, please tell me!
Thank you!
Alex -
If you don't see a list of actual peers then it's not able to reach the pool that is set. Your settings look like the defaults which should be good.
Try resolving
0.pfsense.pool.ntp.orgin Diag > DNS Lookup.Steve
-
Thanks Steve. I performed the DNS lookup and got 4 A records returned:
Results
Result Record type
74.117.214.2 A
72.14.183.39 A
52.6.160.3 A
50.205.244.25 AThe nameservers were 127.0.0.1 and a local pihole I have running on my network. Since the DNS lookup was successful, I'm assuming the use of my own DNS server here is irrelevant?
-
If it helps, here are the last 50 log entries for the NTP server. It looks like its attempting to connect?
Last 50 NTP Log Entries. (Maximum 50)
May 20 06:45:04 ntpd 27062 Soliciting pool server 45.76.244.202 May 20 06:43:58 ntpd 27062 Soliciting pool server 72.14.183.39 May 20 06:42:52 ntpd 27062 Soliciting pool server 52.6.160.3 May 20 06:41:45 ntpd 27062 Soliciting pool server 50.205.244.25 May 20 06:40:38 ntpd 27062 Soliciting pool server 74.117.214.2 May 20 06:39:32 ntpd 27062 Soliciting pool server 54.39.23.64 May 20 06:38:28 ntpd 27062 Soliciting pool server 197.80.150.123 May 20 06:37:21 ntpd 27062 Soliciting pool server 195.43.74.123 May 20 06:36:16 ntpd 27062 Soliciting pool server 131.188.3.221 May 20 06:35:11 ntpd 27062 Soliciting pool server 213.239.217.214 May 20 06:34:06 ntpd 27062 Soliciting pool server 188.68.36.203 May 20 06:32:59 ntpd 27062 Soliciting pool server 178.79.152.182 May 20 06:31:53 ntpd 27062 Soliciting pool server 95.216.78.223 May 20 06:31:52 ntpd 27062 kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized May 20 06:31:52 ntpd 27062 kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized May 20 06:31:52 ntpd 27062 Listening on routing socket on fd #31 for interface updates May 20 06:31:52 ntpd 27062 Listen normally on 10 mvneta0.4092 [fe80::f2ad:4eff:fe09:124a%12]:123 May 20 06:31:52 ntpd 27062 Listen normally on 9 mvneta0.4091 [fe80::1:1%11]:123 May 20 06:31:52 ntpd 27062 Listen normally on 8 mvneta0.4091 192.168.86.1:123 May 20 06:31:52 ntpd 27062 Listen normally on 7 mvneta0.4090 198.74.7.58:123 May 20 06:31:52 ntpd 27062 Listen normally on 6 mvneta0.4090 [fe80::f2ad:4eff:fe09:124a%10]:123 May 20 06:31:52 ntpd 27062 Listen normally on 5 lo0 127.0.0.1:123 May 20 06:31:52 ntpd 27062 Listen normally on 4 lo0 [fe80::1%7]:123 May 20 06:31:52 ntpd 27062 Listen normally on 3 lo0 [::1]:123 May 20 06:31:52 ntpd 27062 Listen normally on 2 mvneta0 [fe80::f2ad:4eff:fe09:124a%1]:123 May 20 06:31:52 ntpd 27062 Listen and drop on 1 v4wildcard 0.0.0.0:123 May 20 06:31:52 ntpd 27062 Listen and drop on 0 v6wildcard [::]:123 May 20 06:31:52 ntpd 27062 gps base set to 2019-05-05 (week 2052) May 20 06:31:52 ntpd 27062 basedate set to 2019-04-29 May 20 06:31:52 ntpd 27062 proto: precision = 0.400 usec (-21) May 20 06:31:52 ntpd 26843 Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid May 20 06:31:52 ntpd 26843 ntpd 4.2.8p13@1.3847-o Sat May 11 02:49:14 UTC 2019 (1): Starting May 20 06:31:52 ntpd 59815 ntpd exiting on signal 15 (Terminated) May 20 06:31:12 ntpd 59815 Soliciting pool server 68.183.65.77 May 20 06:30:07 ntpd 59815 Soliciting pool server 193.1.12.167 May 20 06:29:00 ntpd 59815 Soliciting pool server 104.236.52.16 May 20 06:27:53 ntpd 59815 Soliciting pool server 72.30.35.89 May 20 06:26:47 ntpd 59815 Soliciting pool server 4.53.160.75 May 20 06:25:40 ntpd 59815 Soliciting pool server 195.21.137.209 May 20 06:24:35 ntpd 59815 Soliciting pool server 72.30.35.89 May 20 06:23:30 ntpd 59815 Soliciting pool server 173.230.144.109 May 20 06:22:24 ntpd 59815 Soliciting pool server 129.250.35.251 May 20 06:21:19 ntpd 59815 Soliciting pool server 107.181.191.189 May 20 06:20:12 ntpd 59815 Soliciting pool server 85.25.210.112 May 20 06:19:08 ntpd 59815 Soliciting pool server 198.50.238.156 May 20 06:18:01 ntpd 59815 Soliciting pool server 194.58.200.20 May 20 06:16:56 ntpd 59815 Soliciting pool server 88.198.34.135 May 20 06:15:52 ntpd 59815 Soliciting pool server 194.192.112.20 May 20 06:14:45 ntpd 59815 Soliciting pool server 139.112.153.38 May 20 06:13:40 ntpd 59815 Soliciting pool server 74.6.168.72 -
Yeah that seems fine. So it clearly can't actually reach those for some reason.
Try to ping or traceroute to one of those IPs from the firewall.
It is also possible that ntp is rejecting the peers because the time is so far out. You can manually set the date/time at the command line using the date command.
https://www.freebsd.org/cgi/man.cgi?query=dateSteve
-
Good suggestion.
This seems odd to me. I can ping / traceroute any of the A record IPs returned just fine along with those in the log. Steve you're correct it certainly must be a connectivity issue somewhere as I'm able to set the clock manually per your suggestion, but accompanying the newly set date in the command output is the message "date: can't reach time daemon, time set locally"
I'm not sure where to look from here, but it would appear all is functioning normally from the pfSense / sg-1100 side.
Guess my only option is to stick with the manually entered time for now.
-
@ahoeppner said in SG-1100 incorrect date and time:
Guess my only option is to stick with the manually entered time for now.
That was in idea to get you into the ballpark. Being too far off the pool time may result in a no-sync.
You can try to use your local gov's NTP servers as well
time-a-g.nist.gov 129.6.15.28 (Gaithersburg, Maryland)
time-b-g.nist.gov 129.6.15.29
time-c-g.nist.gov 129.6.15.30
time-a-b.nist.gov 132.163.96.1 (Boulder, Colorado)
time-b-b.nist.gov 132.163.96.2
time-c-b.nist.gov 132.163.96.3AFAIK those are not pools so it makes more sense to use their IPs instead of the IPs of an ntp.org pool.
