Hello Ian and Guy,
>>>> ethereal@xxxxxxxxxxxxx 11/03/04 06:19PM >>>
> [snip]
> 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.
> [snip]
> 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
If it matters, my trusty old copy of NAI v3.5 Sniffer
recognizes and parses the ISL frames in spite of the
fact that the ISL frame "length" fields are zero (0x0000).
But I just did a test on a Cisco 6509 with an ISL trunk and
in this instance the captured data includes non-zero
length fields. What was even more surprising was that
with ALL the recent Ethereal versions the 6509 generated
ISL encapsulated data was identified as ISL and the
encapsulated frames extracted and parsed.
So this thread's Subject line really should have read:
"v0.9.9 through v0.10.7 can't recognize Cisco ISL
frames with 0x0000 length field"
But as I said in my original post "I'm quite too naive". ;-)
FWIW: My exposure to ISL is occasional and accidental.
It occurs when someone forgets to explicitly configure one
of our Cisco c3500xl series switch trunk ports to support
802.1Q (the default is ISL). Since we don't use ISL I hadn't
really cared when the pre-0.9.9 versions of Ethereal only
parsed the ISL headers and ignored the encapsulated
payloads when presented with ISL packets containing a
0x0000 length field. At the time it didn't even occur to me
that Ethereal could/would have parsed the encapsulated
frames given a valid length field.
Now it has been quite a while (maybe two years or so)
since we've mis-configured any trunks where someone
felt it necessary to create a trace to help diagnose the
problem. But in the last week we've had two occurrences
while deploying BlueSocket Access Gateways.
We used BlueSocket's trace facility to sniff the "managed"
interface (which is supposed to be an 802.1Q trunk).
We then used Ethereal 0.10.7 to review these trace files.
In both cases Ethereal reported that the BlueSocket was
receiving "FC" " (Fibre Channel) frames. It was obvious
that the "Fiber Channel" identification was a mistake, but
it wasn't immediately obvious that we were looking at ISL
traffic generated by a mis-configured Cisco c3500xl series
switch trunk port.
Thanks again Guy and Ian for looking into this ISL 0x0000
length identification/parsing anomaly.
Best regards,
Jim Y.