On Thu, Jun 26, 2003 at 01:32:44AM +0200, Rostislav Letos wrote:
> We looked into the issue, and it seems that for historical reason
> ETHEREAL decreases packet size which is stored in packet data record
> struct-0x1005 (assuming it includes FCS bytes) before reading packet
> data.
It's not done for "historical reasons". It's done because many
LANalyzer captures appear to have, in their data records, a length in
"rx_frm_len" that's larger than the length in "rx_frm_sln" by 4 bytes,
but that's *less* than the length in the "mxslc" value in the summary
header - so it's not as if those 4 bytes were sliced off of the packet
because they went past a user-specified slice length.
If we report to Ethereal a packet length equal to "rx_frm_len" and a
captured length equal to "rx_frm_sln", it reports, for every packet,
different "bytes on wire" and "bytes captured" values, *and* it means
that any dissector that processes the entire "bytes on wire" value
(which is what they should do, so that the dissection is based on the
actual size of the packet, not on the sliced size) will throw an
exception even if the sliced-off data happens to be an FCS rather than
actual Ethernet or Token Ring payload.
> I know the old LANalyzer included FCS bytes here, but according to
> official TR1 file format documentation, this variable should keep length
> of stored packet data.
According to the LANalyzer format documentation at
http://secinf.net/info/nw/lan/trace.txt
the fields are
WORD rx_frm_len Length of the packet in bytes
WORD rx_frm_sln Length of packet slice in bytes
Presumably the "length of packet slice" is the amount of data in the
record (although there's a typo in the spec - it says
BYTE data[tx_frm_sln] Packet data
but they presumably meant "rx_frm_sln", not "tx_frm_sln", as there isn't
a "tx_frm_sln" field). "Length of the packet in bytes" doesn't specify
whether it includes the FCS or not; it could be read as including the
FCS and, from the LANalyzer captures I've seen, it appears that Novell
meant it to include the FCS.
> So I would clasify this as a bug in ETHEREAL.
>
> The correct handling here should be to determine available packet data
> length by comparing this stored value with length counted from packet
> record (0x1005, record length-32bytes). This way you can avoid cutting
> 4 bytes from the packet in case exact packet length is stored there.
Unfortunately, there's no "correct handling" in Ethereal that would
always do the right thing, unless your NETMON never does packet slicing
(other than perhaps slicing the FCS off).
Something that would handle
1) LANalyzer files in which the "length of the packet in
bytes" is the length including, presumably, the FCS, and in
which the "length of packet slice in bytes" never includes
the FCS (*ALL* the LANalyzer captures I've seen are like that -
have you seen any that aren't?), so that "rx_frm_len" is
always greater than "rx_frm_sln" by at least 4
and
2) files from NETMON *if* no slicing is done, so that
"rx_frm_len" and "rx_frm_sln" are the same
whould be to make the "bytes on wire" value be the maximum of
"rx_frm_len - 4" and "rx_frm_sln", so that:
1) in the first case, "rx_frm_len - 4" will be >= "rx_frm_sln",
and Ethereal will work as it does now;
2) in the second case, "rx_frm_len - 4" will be < "rx_frm_sln",
and both lengths will be reported as "rx_frm_sln".
