Wireshark-bugs: [Wireshark-bugs] [Bug 10440] NTP timestamp decoding
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Thu, 04 Sep 2014 02:17:58 +0000

Comment # 9 on bug 10440 from 
(In reply to Michael Sukhar from comment #6)
> (In reply to Jeff Morriss from comment #5)
> > RFC 4330 updated the definition of the timestamp; Wireshark uses the updated
> > definition:
> > 
> > ~~~
> >       As the NTP timestamp format has been in use for over 20 years, it
> >       is possible that it will be in use 32 years from now, when the
> 
> RFC 4330 is for NTP V4. The attached log is for NTP V3. Is this change in
> Timestamp value interpretation applicable retroactively to the earlier
> versions of NTP?

Yeah, that I can't tell you.  It makes some sense since NTP implementations
certainly don't care about time before 1970.

(In reply to Michael Sukhar from comment #7)
> If I read RFC 4330 above right for NTP v4 timestamp value 0 should be "6h
> 28m 16s UTC on 7 February 2036". It's not, see the attached pcap.

Well, the NTP format described in RFC 4330 also says:

   There will exist a 232-picosecond interval, henceforth ignored, every
   136 years when the 64-bit field will be 0, which by convention is
   interpreted as an invalid or unavailable timestamp.

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