Re: Tcpdump time discrepancy (vs ethereal/tcptrace)

[Guy Harris <guy () alum mit edu>]

On Jul 22, 2004, at 1:47 PM, Aaron Mitchell wrote:

> I've noticed a peculiar behavior.  Given the same hand-crafted
> dump file (with an intended time of 5:36 on Jan 1, 1970), tcpdump
> reports a time of 6:36 for default output, and a time of 10:36 when
> run with the -tttt option ("supposedly" same time with date info
> prepended).  Both ethereal and tcptrace report the predicted time of
> 5:36.

Funny, Ethereal says 2:36 here.  Perhaps my being in California and you 
presumably being in Ohio has something to do with that. :-)

Mac OS X 10.3.4's tcpdump says 3:36, and says 10:36 with -tttt.

Current CVS top-of-tree tcpdump says 3:36 in both cases, as does 
current CVS x.8 tcpdump; the problem with -tttt is a bug fixed after 
the version used in OS X 10.3.4 (3.8.3) was released.

The 2:36 vs. 3:36 problem is due to tcpdump, for some reason, 
converting times by getting the offset from UTC at the time the capture 
starts, and using that.  That works fine if you're running a live 
capture (*and* that capture doesn't span a standard <-> summer time 
change...), but doesn't work as well if you're reading from a capture 
file made at a time when the local offset from UTC was different from 
what it is now.

In most of the US and Canada, it's currently Daylight Savings Time, but 
it wasn't DST there in January 1, 1970, hence the problem.

I assume the rationale for the time conversion being done that way is 
that it's faster than using "localtime()" (and/or perhaps a desire to 
have it use the same offset throughout the capture, if there are any 
post-processing scripts that parse the times and do arithmetic on them 
- but those scripts should be using "-tt", which gives you raw seconds 
and microseconds) and that the speedup made something work well that 
wouldn't work well if "localtime()" were used.

If that's still valid, we should probably have it set "thiszone" to 
"gmt2local(time stamp of first packet)" after reading, but before 
processing, the first packet, so the offset from UTC is appropriate to 
the time of the first packet, not to the time when tcpdump called 
"time()" in "gmt2local()".

If that's *not* still valid, we should just use "localtime()" and be 
done with it.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.