Problem with NTP; different clients give different results.



  • 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:


  • LAYER 8 Global Moderator

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

    timestamp.png



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


  • LAYER 8 Global Moderator

    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.



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


  • LAYER 8 Global Moderator

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



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

  • LAYER 8 Global Moderator

    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.


  • LAYER 8

    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.
    

  • LAYER 8 Global Moderator

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


  • LAYER 8

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


  • LAYER 8 Global Moderator

    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.



  • @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



  • 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



  • @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).


  • LAYER 8 Global Moderator

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


Log in to reply