Comment # 11
on bug 10190
from Guy Harris
So the NetMon 2.3 file format document, even when combined with the NetMon 3.4
NPL files, is incomplete, and have multiple different interpretations.
The first possible interpretation I see is:
In 2.0 format, packets don't have trailers, so they don't have UTC time
stamps, and there is no ExtendedInfoOffset field in the file header, there is
instead a NetworkInfoOffset field;
in 2.1 format, packets have trailers, containing a 2-byte per-frame MAC
type, but no UTC time stamp, and there is no ExtendedInfoOffset field in the
file header, there is instead a NetworkInfoOffset field;
in 2.2 format, packets have trailers, containing a 2-byte per-frame MAC
type and a 2-byte index into the process information table, but no UTC time
stamp, and there is no ExtendedInfoOffset field in the file header, there is
instead a NetworkInfoOffset field;
in 2.3 format, packets have trailers, containing a 2-byte per-frame MAC
type, a 2-byte index into the process information table, an 8-byte UTC time
stamp, and a 1-byte time zone index, and there is an ExtendedInfoOffset field
in the file header, and the UTC time stamp and time zone index should be
ignored if the ExtendedInfoOffset field is zero.
I suspect this is how NetMon 3.4 interprets it - the UTC time stamp and time
zone index are not present unless the version number is 2.3 or greater, even if
the NetworkInfoOffset/ExtendedInfoOffset field is non-zero, and, if the version
number is 2.3 or greater, those fields are ignored if the ExtendedInfoOffset
field is zero. (I.e., "This is used if and only if ExtendedInfoOffset in the
capture file header is not 0." really means "This is used if and only if
ExtendedInfoOffset is present in the capture file header and is not 0.", and
the field is *not* present in pre-2.3 files.)
The other interpretation is that:
if the field in the file header at the position of the ExtendedInfoOffset
is non-zero, records have trailers, and the trailers have a UTC time stamp and
time zone, even if the version number is less than 2.3, but:
for 2.0, the only fields to process in the trailer are the UTC time
stamp and time zone offset;
for 2.1, the only fields to process in the trailer are the MAC type,
the UTC time stamp, and the time zone offset;
for 2.2 and later, the fields to process in the trailer are the MAC
type, the process information table index, the UTC time stamp, and the time
zone offset;
if the field in the file header at the position of the ExtendedInfoOffset
is zero:
for 2.0, there is no trailer;
for 2.1, the only field to process in the trailer is the MAC type;
for 2.2 and later, the only fields to process in the trailer are the
MAC type and the process information table index.
I suspect that the first interpretation is the one that was intended by the
Network Monitor developers, and what Network Monitor implements.
If the first interpretation is correct, then Message Analyzer is writing out
incorrect files and needs to be fixed.
If the second interpretation is correct, then Network Monitor 3.4 is incorrect,
and needs to be fixed in order to read Message Analyzer .cap files.