Ethereal-dev: Re: [Ethereal-dev] v0.9.9 through v0.10.7 can't recognize Cisco ISL frames
On Nov 3, 2004, at 3:28 PM, Guy Harris wrote:
The length field is the one causing the problem with the current
dissector. Is it supposed to be zero? According to the ISL document
at the URL you sent, it "stores the actual packet size of the original
packet as a 16-bit value. The LEN field represents the length of the
packet in bytes excluding the DA, TYPE, USER, SA, LEN, and FCS fields.
The total length of the excluded fields is 18 bytes, so the LEN field
represents the total length minus 18 bytes." That seems to suggest
that there's actually no encapsulated packet of any sort past the FCS
(CRC) field.
There's at least some evidence that we've seen packets where the LEN
field was actually generated with a real length, we saw this in
http://www.ethereal.com/lists/ethereal-dev/200307/msg00106.html, and
since it wasn't mentioned in this thread from tcpdump-workers
(http://www.tcpdump.org/lists/workers/2001/08/msg00002.html), I assume
that a "valid" length was seen when some of the ISL decoding stuff was
being done in tcpdump as well.
So I suppose it's possible that A) some devices don't supply a value in
LEN, or B) the value was stripped out before the packet was saved for
some reason.
In either case, does LEN actually matter? Especially if A is true,
then like you said (and the Cisco documents say), if LEN should only
ever be the packet length minus 18, then do we need it for anything?
In either A or B above (as well as cases where the field contained a
real value) it would seem to me to be safe to ignore LEN?
I suppose it would be nice to have LEN in cases where there may be
frame padding, corruption, or the ISL FCS is actually stored in the
packet record (and probably things for other media types where ISL is
supported that I haven't thought of), though.
So far doing some quick research I haven't found anyone else that's run
into the zero-value LEN, but it looks like in at least two cases this
list has run into an example...
Ian
