Kevin Johnson wrote:
On Sun, 2005-01-02 at 22:46, Guy Harris wrote:
The only Sniffer captures where timestamp display is not improved are
ATM captures made with the older ATM pods - and these are no worse than
in the existing version of Ethereal - they simply have not changed.
So the "realtick" value in those captures is the same as the value that
the old code chose? What's the file format version number in those
files, and what's the "capture type" (xxj[4]/xxc[4]) value for those
files? Are the time stamps wrong because the units are wrong (in which
case the amount by which the time stamps are off would change from
packet to packet), or because the start time is wrong (in which case all
the time stamps would be off by the same amount)?
Do you have any captures of that sort that you could send us?
Not sure if we can send the captures as they were part of Sniffer
Training and so may not be redistributable. We will check.
If they're not redistributable, it'd still be interesting to see the
answer to the other questions - did your changes not help because the
files didn't have a "realtick" value (i.e., it was 0, which appears to
mean "present"), so that the Ethereal code has to use the hdr.timeunit
field (in which case perhaps the TpS array is wrong - the values in
there have been tweaked to fix problems, but if those problems were with
files where the correct timestamp units were in a non-zero realtick
value, the changes to TpS might have been wrong), or did they not help
because the "realtick" values were wrong?
Did it cause Ethereal to misinterpret the capture?
It made Ethereal use the wrong tick value to determine time stamps.
Which made any time values unusable.
Sorry, I might not have stated that clearly - "it" referred to patching
the capture type value to be 2 rather than 6; that change fixed the time
stamps, but did it then cause Ethereal to misinterpret the packet
contents (e.g., interpreting ISDN traffic as Ethernet traffic)?
As an interesting side note, there is a check being performed to determine whether or not
to honor the FCS bits at the end of each packet. The check is based on the hex values of
two bytes - right in the middle of the time stamp. It turns out these two bytes are only
valid if the "real" time unit is near the 1193180 value, so it is likely Ethereal has been
ignoring the FCS information when some folks think it has been used.
Do you mean "ignoring the FCS information when it's present" or
"treating the data at the end of the packet like an FCS when it's not an
VCS"?
Ignoring it when it is present.
I.e., Ethereal's been treating the 4 bytes at the end of the packet as
junk when it should have been treated as an FCS? If the real check
should be for a "realtick" value near (for some value of "near")
1193180, that check would, I think, make it *less* likely that Ethereal
would treat the 4 bytes at the end of the packet as an FCS, rather than
*more* likely, as it'd involve checking the high-order bits of the
"realtick" value against the proper value, rather than ignoring those
bits as Ethereal has been doing.
I wonder whether the presence of FCS data is, in some sense,
unintentional, i.e. they didn't decide to put it there, some hardware
(whether it's a pod or a regular Ethernet interface) just happens to put
it there sometimes, and when capturing with that hardware, the time
stamp value happens, for whatever reason, to be in the range 1193180.
Does Sniffer ever display those bytes as an FCS?
