Ping's Time Handling: A Technical Deep Dive into Countermeasures Against Clock Rollbacks

The ping utility, a fundamental network diagnostic tool dating back to 1983, contains an interesting feature that many users might never encounter: it implements 'countermeasures' when the system clock rolls backward. This technical deep dive explores the implementation details and implications of this behavior.

The Unexpected Countermeasures Message

When the author powered on their corporate laptop after a holiday, they ran the standard diagnostic ping command before checking email. While the network appeared healthy, ping displayed an unexpected message: "taking countermeasures." This occurred because the system clock had been rolled backward by the NTP daemon before ping completed its initialization.

The ping source code reveals that this "countermeasure" is simply resetting negative round-trip time (RTT) measurements to zero. When ping detects a negative RTT (indicating the receive timestamp is earlier than the send timestamp), it marks the measurement as 0ms rather than reporting an impossible negative value.

For those interested in examining the actual implementation, the iputils ping source code contains the relevant logic in the ping_common.c file's gather_statistics() function.

Ping's Time Measurement Modes

Ping operates in two distinct time measurement modes:

1. Legacy mode (-U): Uses the wall clock via gettimeofday() before sending and after receiving packets. This mode has more jitter.

2. Default mode: Uses "network time" by calling gettimeofday() before sending and obtaining a more accurate receive timestamp from the SO_TIMESTAMP control message (CMSG).

The latter mode is more precise because it leverages hardware timestamps when available, avoiding the syscall overhead and potential inconsistencies of separate gettimeofday() calls. This approach is documented in the Linux man page for ping.

Debugging Time-Related Issues

Investigating ping's time behavior presents unique challenges. Modern Linux systems use the Virtual Dynamic Shared Object (vdso) to optimize certain system calls like gettimeofday(), making them invisible to traditional strace debugging.

The author explored two techniques to bypass vdso:

1. Auxiliary Vector manipulation: Rewriting the AT_SYSINFO_EHDR parameter before execve() completes. This approach requires ptrace() and doesn't work under strace.

2. LD_PRELOAD override: Creating a custom library that forces gettimeofday() and related functions to use actual syscalls instead of vdso. This works but requires removing ping's CAP_NET_RAW capability, as capability-protected programs ignore LD_PRELOAD.

The vdso override implementation demonstrates this technique in action.

Fault Injection and Time Manipulation

Using strace's fault injection feature, the author successfully reproduced the "taking countermeasures" behavior by manipulating gettimeofday() results to simulate a clock rollback. This confirmed that ping's countermeasures only trigger when time appears to move backward.

The investigation revealed ping's clever algorithm for measuring RTT:

1. Set SO_TIMESTAMP socket option to receive timestamps
2. Record send timestamp via gettimeofday()
3. Embed timestamp in ICMP payload
4. Upon receiving reply, extract send timestamp from payload and receive timestamp from CMSG
5. Calculate RTT delta

This approach allows ping to handle an unlimited number of in-flight packets without maintaining a large hash table of timestamps.

Security Implications

The article also explores potential attack vectors:

• Truncated payloads: When packet size is less than 16 bytes, ping skips RTT calculation
• Timestamp spoofing: Malicious actors could craft ICMP responses with manipulated timestamps to either trigger false "countermeasures" messages or create nonsensical RTT values

The author provided a Scapy snippet demonstrating how to craft such spoofed responses, showing how timestamp manipulation can affect ping's measurements.

Leap Seconds and Time Synchronization

In practice, significant clock adjustments are rare, with the most notable exception being leap seconds. These coordinated clock adjustments cause the clock to move backward, which can trigger ping's countermeasures. The article notes that leap seconds are scheduled to be deprecated by 2035, with many environments already using a "leap second smear" technique to avoid abrupt clock jumps.

The International Earth Rotation and Reference Systems Service coordinates these leap second adjustments.

Technical Limitations

While ping's countermeasures are a thoughtful addition, they have limitations:

• They only handle backward clock adjustments, not forward ones
• The underlying Linux API limitations prevent using CLOCK_MONOTONIC for RTT calculation, as it can't be compared against SO_TIMESTAMP values which reference the system clock
• The implementation must balance accuracy with compatibility across diverse system configurations

Conclusion

This investigation reveals that even fundamental tools like ping contain sophisticated handling of edge cases that most users never encounter. The "countermeasures" feature, while seemingly simple, represents thoughtful engineering to handle an unusual but potentially confusing scenario.

For system administrators, this serves as a reminder that unexpected diagnostic messages often have logical explanations rooted in system behavior. When ping reports "taking countermeasures," it's worth checking the system time synchronization status rather than dismissing it as an error.

The exploration also highlights the ongoing challenges in accurate time measurement across distributed systems, particularly when dealing with clock adjustments and leap seconds. As network technologies evolve, these fundamental considerations continue to shape how we implement and interpret diagnostic tools.

For those interested in exploring further, the ping source code is available in most Linux distributions' iputils package, and the author's debugging techniques demonstrate valuable approaches for investigating similar system behaviors.