ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 10008] IPv6 Timestamp Mobility Option shows wrong Timestam

Date: Mon, 21 Apr 2014 07:36:26 +0000

Comment # 2 on bug 10008 from
(In reply to comment #1)
> What is the expected timestamp?  Wireshark v1.6 had been end-of-lifed, but
> the \trunk does dissect the timestamps per RFC 5213 (since
> Iae4115bcdb445c3b8a97edc2317eaccdf2e0a83b).  But as you observed, honoring
> RFC 5213 does give you a "garbage" timestamp.
> 
> The timestamp Wireshark v1.6 produces (Mar 20, 2013 11:17:03.219258000 UTC)
> treats the 8 byte timestamp as being NTP format.  And that's the only way I
> could get those bytes into a sensible timestamp.  Is it possible the tool
> that produced this packet is actually (incorrectly) using NTP format (from
> an older RFC?)

The tool that produced this packet gives a random timestamp.
I'm not sure what do you mean by "garbage" timestamp. It's not a useful
timestamp, but it's valid according to the RFC.
Wireshark could say it's a timestamp that is too large or unrepresentable, but
giving some specific timestamp in 2013 even though the actual timestamp is some
million years in the future doesn't make sense for me.

Was this fixed in a different Wireshark version?

Thanks,

Boaz.


You are receiving this mail because:
  • You are watching all bug changes.