Problem with NTP; different clients give different results.

vidarlo · Aug 28, 2019, 11:11 AM

I have a problem with aquiring time froman NTPd running on PFSense 2.4.4-p3. If I use a ISC NTPd as client, it works, and client gets time correctly. In this case, the pfsense ntpd replies correctly, with it's correct stratum in the "Peer Clock Stratum" field, see attached file ntpdate.pcap.

If I however use a simpler client, a Siemens S7 PLC, it fails to aquire time, and in the reply pfsense claims to be stratum 0, which is obviously rejected. This is detailed in *s7client.pcap.

The pfsense installation is at 192.168.20.1 and 192.168.4.1 - those are two different interfaces of the same pfsense installation. NTPd is enabled on both interfaces.

If there is any more information I can contribute, do not hesitate to ask!

Packet captures:

johnpoz · Aug 28, 2019, 2:11 PM

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

vidarlo · Aug 28, 2019, 11:21 AM

So the fact that the client is somewhat confused about it's current state leads the server to return that it is stratum 0?

johnpoz · Aug 28, 2019, 11:35 AM

Did you validate on pfsense that the ntp was actually valid when you did the query... The timestamps on the sniffs seems to be 15 minutes apart. I am not sure - but guess its possible that if client says the time is 17 years in the future that maybe the server could send back - hey Im not a good source.. Would have to test by setting a client that far in the future.

I would set the date and time on the thing and see what you get back.

Server is saying its unsync'd, so yeah the stratum would not be known.

vidarlo · Aug 28, 2019, 11:36 AM

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

Did you validate on pfsense that the ntp was actually valid when you did the query...

Yes, I did. The time was valid all through the test. It has a stable time.

I would set the date and time on the thing and see what you get back.

The time and date on the client is set, but it has a rather minimal ntp implementation.

johnpoz · Aug 28, 2019, 11:38 AM

There is big difference between the time being correct and the ntp showing sync'd

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..