> 1) different versions have different time stamps
That's the way it seemed to me.
> or
>
> 2) there's some header-file field that indicates the version
Could be, but I only had 2 versions to compare
and couldn't tell which field it might have been.
> but there was at least one capture with a version of 2.001 and units of
> 1/1193180 of a second,
Yup. I was told those captures came from
a Sniffer Pro version 4.something. They
absolutely use that 1/119... time scale.
> so just going back to 1/1000000 of a second, as
> per your patch, would be wrong.
>
> I'm CC'ing the folks in the thread back in February, in case they're not
> currently on ethereal-dev.
FWIW, I'm still on the list, though the project
I was working on that used ethereal is closed.
If Patrick Wolfe <pjw@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> would
send some traces, I'd see what I could make of them.
I've got some v2.002 traces from Jason House <jhouse@xxxxxxxxx>,
but I only had my 2.001 traces for comparison and so punted
on looking for a header field and concluded that the time
scales were based on the version. From my archives, the
time scale he had calculated from his traces was 1 tick
per 0.8382229 microseconds. That's near the v2.001 value
of 0.8380965, but different enough to be cause for some
head-scratching. I never submitted a patch that uses his
scale, however.
For any given version of a Sniffer, the way to beat this
time scale issue down is to save a trace in the "native"
format (eg, .cap) about which we're making guesses and
and then save the trace in the "old" Sniffer format (.enc)
about which Ethereal already knows. Comparing timestamps
on the last packet in each trace should give us the new
format's time scale. Well, modulo aliasing/round-off that
you'd get from the Sniffer when it converted to the .enc
time scale.
At least, that's what I'd do (and will, given the traces).
> Guy
Chris.
