Comment # 10
on bug 10440
from Michael Sukhar
(In reply to Jeff Morriss from comment #9)
> (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.
OK, that makes sense.
>
> (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.
Shouldn't 0 value then be marked as "invalid" instead of decoded as "Jan 1st,
1970"? This is of course an edge case and makes little practical difference.
However such cases often hide stack vulnerabilities.
You are receiving this mail because:
- You are watching all bug changes.