Wireshark · Ethereal-dev: Re: [Ethereal-dev] v0.9.9 through v0.10.7 can't recognize Cisco ISLframes

["Jim Young" <SYSJHY@xxxxxxxxxxxxxxx>]

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.