Problem with NTP; different clients give different results.

vidarlo · Aug 28, 2019, 11:44 AM

I'm aware of the difference. And yes, it was synchronized and had a valid time.

The reach field shows 377 for all selected peers on the server. ntptime also shows sync:

$ ntptime
  ntp_gettime() returns code 0 (OK)
  time e110e761.b408b760  Wed, Aug 28 2019 11:43:29.703, (.703258928),
  maximum error 181125 us, estimated error 3512 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -920.327 us, frequency 3.846 ppm, interval 4 s,
  maximum error 181125 us, estimated error 3512 us,
  status 0x2001 (PLL,NANO),
  time constant 7, precision 1.000 us, tolerance 496 ppm,
  pps frequency 4.251 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.

johnpoz · Aug 28, 2019, 12:52 PM

Well my "guess" then it has to do with the client time being so far off that the ntp server returns back that is not going to be a valid source - just a guess.

Put a different client on this lan, and test syncing to the ntp.

kiokoman · Aug 28, 2019, 1:15 PM

the time is too far off
syncing it would cause issues with software timers, strange gaps in log files etc.
launching ntpdate with this flag

-b     Force  the  time  to  be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a
             startup file at boot time.

ntpd have this flag

-g, --panicgate
             Allow the first adjustment to be Big.  This option may appear an unlimited number of times.

             Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set  to  any  value
             without  restriction;  however,  this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with
             the -q and -x options.  See the tinker configuration file directive for other options.

johnpoz · Aug 28, 2019, 1:10 PM

I don't know if his client supports using ntpdate like that?

But I know for sure that such a difference, 17 years not going to make for good stuff..

But his overall question - which I don't have the answer to is why the server responds back with no stratum.

I would test from a client also on this same lan to the same IP, etc. and what does it show back..

kiokoman · Aug 28, 2019, 1:14 PM

i think it's just a placeholder it see the gap, refuse to sync and not accepting any other information

johnpoz · Aug 28, 2019, 1:21 PM

Could well be... He needs to get his time on his client closer and see what happens then with the ntp sync would be my suggestion.

JKnott · Aug 28, 2019, 2:19 PM

@johnpoz said in Problem with NTP; different clients give different results.:

your s7 client says the reference time is year 2036.. Prob going to be some issues there ;)

Actually, that's intentional, for security.

For example, here's a capture I just made, between my Linux computer and pfSense:
Client
Network Time Protocol (NTP Version 4, client)
Flags: 0x23, Leap Indicator: no warning, Version number: NTP Version 4, Mode: client
Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: 6 (64 sec)
Peer Clock Precision: 4294967296.000000 sec
Root Delay: 0 seconds
Root Dispersion: 0 seconds
Reference ID: NULL
Reference Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Origin Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Receive Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Transmit Timestamp: Dec 13, 2070 20:36:43.881077365 UTC

Server
Network Time Protocol (NTP Version 4, server)
Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, Mode: server
Peer Clock Stratum: secondary reference (3)
Peer Polling Interval: 6 (64 sec)
Peer Clock Precision: 0.000002 sec
Root Delay: 0.018310546875 seconds
Root Dispersion: 0.0140380859375 seconds
Reference ID: 132.246.11.238
Reference Timestamp: Aug 28, 2019 14:14:36.965628826 UTC
Origin Timestamp: Dec 13, 2070 20:36:43.881077365 UTC
Receive Timestamp: Aug 28, 2019 14:14:51.403424458 UTC
Transmit Timestamp: Aug 28, 2019 14:14:51.403455935 UTC

And from the pfSense WAN side last week:

Client
Network Time Protocol (NTP Version 4, client)
Flags: 0x23, Leap Indicator: no warning, Version number: NTP Version 4, Mode: client
Peer Clock Stratum: secondary reference (3)
Peer Polling Interval: 9 (512 sec)
Peer Clock Precision: 0.000002 sec
Root Delay: 0.017425537109375 seconds
Root Dispersion: 0.0239715576171875 seconds
Reference ID: 132.246.11.238
Reference Timestamp: Aug 20, 2019 16:21:22.937971724 UTC
Origin Timestamp: Aug 20, 2019 16:21:22.928525035 UTC
Receive Timestamp: Aug 20, 2019 16:21:22.937971724 UTC
Transmit Timestamp: Aug 20, 2019 16:30:02.932939781 UTC

Server
User Datagram Protocol, Src Port: 123, Dst Port: 44719
Network Time Protocol (NTP Version 4, server)
Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, Mode: server
Peer Clock Stratum: secondary reference (2)
Peer Polling Interval: 9 (512 sec)
Peer Clock Precision: 0.000000 sec
Root Delay: 9.1552734375e-05 seconds
Root Dispersion: 0.00335693359375 seconds
Reference ID: 209.87.233.52
Reference Timestamp: Aug 20, 2019 16:29:26.706151139 UTC
Origin Timestamp: Aug 20, 2019 16:31:44.921310040 UTC
Receive Timestamp: Aug 20, 2019 16:31:44.942857706 UTC
Transmit Timestamp: Aug 20, 2019 16:31:44.942889384 UTC

JKnott · Aug 28, 2019, 3:37 PM

I just noticed a difference between Linux and Windows 10. Windows 10 uses NTP 3, but Linux NTP 4. Also, there are no "funny" values in the server packet and in the client packet, both the origin and transmit timestamps are for the current time.

Network Time Protocol (NTP Version 3, client)
Flags: 0xdb, Leap Indicator: unknown (clock unsynchronized), Version number: NTP Version 3, Mode: client
Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0.000000 sec
Root Delay: 0.020263671875 seconds
Root Dispersion: 8.97770690917969 seconds
Reference ID: NULL
Reference Timestamp: Aug 28, 2019 15:28:47.072085699 UTC
Origin Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Receive Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Transmit Timestamp: Aug 28, 2019 15:30:59.713089499 UTC

Network Time Protocol (NTP Version 3, server)
Flags: 0x1c, Leap Indicator: no warning, Version number: NTP Version 3, Mode: server
Peer Clock Stratum: secondary reference (3)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0.000002 sec
Root Delay: 0.0184326171875 seconds
Root Dispersion: 0.0333404541015625 seconds
Reference ID: 132.246.11.238
Reference Timestamp: Aug 28, 2019 15:07:13.948361143 UTC
Origin Timestamp: Aug 28, 2019 15:30:59.713089499 UTC
Receive Timestamp: Aug 28, 2019 15:30:59.902306393 UTC
Transmit Timestamp: Aug 28, 2019 15:30:59.902336671 UTC

vidarlo · Aug 29, 2019, 6:39 AM

@johnpoz

The NTP client syncs fine to a different NTP server. And time on the NTP client is not 2036; it's within minutes of NTP time. Furthermore, it's an embedded client, probably stateless (think sNTP).

johnpoz · Aug 29, 2019, 9:13 AM

Well then your not ttalking to pfsense is the only thing I can think of dude.. did you do my test of trying to sync a different client to that same IP your using..