Wireshark-bugs: [Wireshark-bugs] [Bug 6114] New: For ICMP Time Response, In detail pane, Timesta

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Tue, 12 Jul 2011 21:20:06 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6114

           Summary: For ICMP Time Response, In detail pane, Timestamp is
                    incorrectly decoded for MS Windows.
           Product: Wireshark
           Version: 1.6.0
          Platform: x86
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
        ReportedBy: marbert@xxxxxxxxxx


Created an attachment (id=6651)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6651)
Screenshot

Build Information:
Version 1.6.0 (SVN Rev 37592 from /trunk-1.6)

ICMP replies from MS Windows 7 and MS Windows XP SP3.
--
For ICMP Time Stamp Response (type 14), the 2 responder's fields (Receive
Timestamp and Transmit Timestamp) contain a 32 bit number for milliseconds
since midnight UTC.  These are interpreted and displayed in the easy to read
form "h, m, s.ss".  Values displayed do not make sense, varying from 24d, 6h,
3m, 57.312s to -6d, 56m, 48.384s.  It appears that the interpreted values are
calculated assuming left-justified (MSB on the left), where in fact the 32 bit
values are right-justified (MSB on the right) (1).  The raw values
corresponding to the above interpreted times are 7c e5 d6 00, and e0 e5 d6 00
respectively.

This was also seen in earlier versions of Wireshark.

Reference (1):
http://tools.ietf.org/html/rfc778
...
"The timestamp values are in milliseconds from  midnight
UT and are stored right-justified in the 32-bit fields shown
above.  Ordinarily,  all  time  calculations  are  performed
modulo-24 hours in milliseconds."


Not sure why, but the *sender's* field containing the Originate Timestamp
appears *left* justified and is interpreted seemingly correctly.  Here the
value is 00 d6 e4 84, and interpreted as 3h, 54m, 43.204s.  It would seem that
the Windows implementation of rfc778 uses different justifications for Sender
and Responder?  If Windows is wrong, should Wireshark compensate?

--Norbert

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.