On May 14, 2009, at 7:20 PM, Jefferson Ogata wrote:
But the point of storing the mostly irrelevant zone data as metadata
is so that it can be recorded when pcap timestamps are UTC, as they
always should have been. I'd like to find the person who decided to
store localtime instead of gmtime in the pcap timestamp field and
smack him or her with a large sock filled with horse manure.
What application or applications make that mistake?
Libpcap returns, for most platforms, whatever time stamp the kernel
coughs up, which is, on all the platforms with which I'm familiar, a
UNIX time stamp, hence GMT. The only exceptions I know of are:
1) HP-UX, where the kernel supplies no time stamp - but libpcap calls
gettimeofday(), returning a UNIX time stamp, hence GMT;
2) the support for SS7 captures on Septel/Intel boards - again,
libpcap calls gettimeofday();
3) the support for USB Linux captures in text mode - again, libpcap
calls gettimeofday();
4) Gisle Vanem's support for DOS - I'm not sure what gettimeofday2()
does, but if it doesn't return GMT, that's probably because of a
platform limitation.
tcpdump and Wireshark, at least, use libpcap to do capturing, so they
write out GMT time stamps.
Presumably whatever application stores local time in pcap files either
1) doesn't use libpcap, but uses something that returns local time
(in which case, whoever wrote that code desperately needs to be hit
upside the head with said sock);
or
2) does, but "helpfully" converts the time to local time (in which
case, whoever decided to be "helpful" needs to be hit with said sock).
WinPcap also at least attempts to supply GMT time stamps, within the
limitations of the Windows kernel; I have the impression that enough
information is available for it to succeed at that (NTFS, for example,
has to be able to write out GMT time stamps for files, so kernel code
can get GMT time stamps).
However, even with standard pcap files, which have GMT time stamps,
one might want to be able to display the time stamps in the time zone
in which the capture was done rather than in the time zone in which
it's being read; that's what the original poster wanted. Storing time
zone information in the file, rather than getting it out of band
(e.g., asking whoever sent you the file where they captured it) isn't
a requirement, but it could be a convenience.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.