ping -s timestamp format ??

[Phil Shaw]

I'm trying to figure out the format of the timestamp Win2K
displays when you use the "ping -s" command.

For example:

ping -s 1 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 171628803
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 4097693955
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 3879852291
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 3678787843

Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

If you translate to hex, you can see that it's a 32 bit
binary field, but nothing else seems to be consistent.

Microsoft tells me what it isn't ... It isn't milliseconds
since midnight Universal Time as defined in the ICMP
standard (RFC 792). It says so here:

http://support.microsoft.com/default.aspx?scid=kb;en-
us;156165

No word there of the actual format. A secret maybe ??

There's some discussion of Windows timers here, but none
seem to fit:
http://support.microsoft.com/default.aspx?scid=kb;en-
us;81592

Does anybody know how to interpret this timestamp? Or
can anyone suggest some way other than using ping -s to
get accurate network traversal times to a destination host
from Win2K?

 

[luc wastiaux]

I'm trying to figure out the format of the timestamp Win2K
displays when you use the "ping -s" command.

For example:

ping -s 1 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 171628803
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 4097693955
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 3879852291
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Timestamp: 127.0.0.1 : 3678787843

You have to understand what the -s option really does. Running ping /?
on windows 2000 tells us that activating this option will print the
timestamps for the n first hops.

What actually happens is that when you use that option, your outgoing
ICMP echo request packets are sent out with with the IP timestamp
option, more precisely with IP timestamp and flag 1, meaning each router
along the path of your ICMP packet inserts it's IP+TIMESTAMP in a
special zone of the IP header. There is room for only four IP+TIMESTAMP
pairs in the header, hence the limitation to 4 hops in the ping -s command.

The standard timestamp that gets added by a router when this option is
activated, is the number of milliseconds past midnight (UTC).

This is what is SUPPOSED to happen.

However I have run some tests (ping -s 4 <someinternethost>), and while
the tcpdump output I was monitoring on my router was consistent, I have
no idea how the **** microsoft's ping manages to mess-up the timestamps
it gets in return - they don't make sense. My guess is microsoft's ping
is broken, maybe you can find a replacement somewhere on the web ?