Wireshark · Ethereal-dev: [Ethereal-dev] Re: some netxray traces off by time factor

[Matt Jibson <dolmant@xxxxxxxxx>]

After more research, this problem seems to be happening because the
Netasyst files use a slightly different format than the Sniffer files,
even though they are parsed by the same importer.

The working file:
hdr.timeunit = 2
hdr.realtick = 0x001234de = 1193182
It's timeunit thus ends up as 1193182, since hdr.realtick != 0.

The broken  file:
hdr.timeunit = 0
hdr.realtick = 0x369e99 = 3579545
It's timeunit is 3579545, since hdr.realtick != 0.
This broken file is fixed by: timeunit /= 3.579545, which yields a
timeunit of 1000000. This corresponds to TpS[0], or TpS[hdr.timeunit].
This is important around line 420 of wiretap/netxray.c.

The attached file is the broken file. It should be 309 seconds, not
the 86 that Ethereal displays it at. It isn't difficult to fix this,
but I don't have enough other files of this type to test against to
see if breakage would happen. Any help?

-Matt Jibson

On 7/21/05, Matt Jibson <dolmant@xxxxxxxxx> wrote:
> When looking at a trace generated by Airmagnet, we found that all of
> the times generated were short by a factor of 3.579541427. We did some
> tests and found that creating a trace with Sniffer (which, in the
> summary dialog, has a format string of "Network Associates Sniffer
> (Windows-based) 2.00x") displays all packets with the correct times.
> When we generated a trace using Netasyst, which has the exact same
> format string, Ethereal lists the times as being off by the above time
> factor. If someone would like to help fix this bug, I can email you
> some traces. This happens with 0.10.11 and SVN 14905.
> 
> -Matt Jibson
>

Attachment: 30SecondKeepAlives.cap
Description: Binary data