Ntp

From ConShell
Jump to: navigation, search

Shown below is a recent packet trace of an NTP transaction, followed by my interpretation.

[root@lu100 ~]$ /usr/sbin/tcpdump -s0 -n -c2 -v host 10.1.6.1 
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 
10:02:03.940685 IP (tos 0x10, ttl  64, id 442, offset 0, flags [DF], proto 17, length: 76) 
 10.1.11.240.ntp > 10.1.6.1.ntp: NTPv4, length 48
        Client, Leap indicator: clock unsynchronized (192), Stratum 0, poll 6s, precision -20
        Root Delay: 0.000000, Root dispersion: 0.013259, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3364124387.999978999 (2006/08/09 07:59:47)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3364124387.999978999 (2006/08/09 07:59:47) 
10:02:03.941463 IP (tos 0xc0, ttl 255, id 0, offset 0, flags [none], proto 17, length: 76) 
 10.1.6.1.ntp > 10.1.11.240.ntp: NTPv4, length 48
        Server, Leap indicator:  (0), Stratum 3, poll 6s, precision -18
        Root Delay: 0.002883, Root dispersion: 0.000625, Reference-ID: 10.1.6.6
          Reference Timestamp:  3364124252.907320057 (2006/08/09 07:57:32)
          Originator Timestamp: 3364124387.999978999 (2006/08/09 07:59:47)
          Receive Timestamp:    3364124312.042339830 (2006/08/09 07:58:32)
          Transmit Timestamp:   3364124312.042352830 (2006/08/09 07:58:32)
            Originator - Receive Timestamp:  -75.957639169
            Originator - Transmit Timestamp: -75.957626169
2 packets captured
108 packets received by filter
46 packets dropped by kernel

The client (10.1.11.240) sends a poll packet to the server (10.1.6.1) with it's current timestamp and indicating 'unsyncronized'. The server, running at Stratum 3, then sends a reply packet (port 123/udp) with it's timestamp. There is no "acknowledgement" by the client at any point over the network, it's up to the client being correctly configured as to whether it will believe or trust the packet from the server.

Note that these packets are not authenticated or encrypted in any way.