I just uploaded a new version of the spec here http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat_ts.html
I tried to spedify the timestamps better and renamed if_tsaccur into if_tsresol. Let me know if you think it makes more sense. Have a nice day GV ----- Original Message ----- From: "Gianluca Varenni" <[EMAIL PROTECTED]> To: "Developer support list for Wireshark" <[email protected]> Sent: Monday, January 21, 2008 9:36 AM Subject: Re: [Wireshark-dev] pcap-ng support > > ----- Original Message ----- > From: "Ulf Lamping" <[EMAIL PROTECTED]> > To: "Developer support list for Wireshark" <[email protected]> > Sent: Friday, January 18, 2008 2:41 AM > Subject: Re: [Wireshark-dev] pcap-ng support > > >> Gianluca Varenni schrieb: >>> What doesn't work: >>> - timestamps are wrong. There are two problems here: >>> 1. the IDB option for the timestamp precision is not decoded, and I >>> was generating timestamps with nanosecond precision. >>> 2. timestamps are not in the libpcap fashion (seconds and >>> microseconds, or seconds and nanoseconds). It's a single 64bit >>> quantity that is split into high and low 32bits. >> Well, I've implemented the first IDB options now in SVN *24133*, >> if_tsaccur (only values 6 and 9 for now) and if_fcslen. So both >> timestamps and FCS should work ok now. >> >> FCS indeed looks ok, but the timestamps are still odd in icmp2.ntar. >> >> According to >> http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionpb, >> the timestamp isn't a 64bit quantity, but the usual pcap way of 32bit >> seconds from 1/1/1970 and 32 bits fractional second. >> >> Do I miss something here? > > I think the description of timestamp formats is quite bad in the specs. > The timestamps are represented as a 64bit quantity split into high and low > 32 bits, that represent the number of microseconds/nanoseconds/??? from > 1/1/1970 (that's the meaning of in "in standard unix format i.e. since > 1/1/1970"). > The reason behind using a single 64bit quantity instead of > seconds/subseconds is twofold: > 1. if we use seconds and subseconds, 32bits don't allow to go under the > nanosecond. > 2. several hardware-based capture cards represent timestamps as > nanoseconds/microseconds as a single 64bit quantity i.e. they don't split > them into seconds and subseconds. > > BTW, there was a discussion on the timestamp format on the ntar-workers > mailing list, here > > http://www.winpcap.org/pipermail/ntar-workers/2006-March/000122.html > > >> >> Regards, ULFL >> >> P.S. AFAIK (I'm not a native english speaker), if_tsaccur is actually >> the resolution and not the accuracy (as the name implies) nor the >> precision (as the text of is_tsaccur implies). Should we change the name >> of if_tsaccur to if_tsresol in the spec? Otherwise if we want to add a >> accuracy / precision option later (which I think we'll going to need), >> these names could get pretty confusing! > > I'm not a native english speaker either, but you are probably right. > Anyone > with different thoughts about it? > This change is a breaking change in the NTAR API, but it's ok. > > Have a nice day > GV > > >> _______________________________________________ >> Wireshark-dev mailing list >> [email protected] >> http://www.wireshark.org/mailman/listinfo/wireshark-dev > > _______________________________________________ > Wireshark-dev mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
