Joshua Oelrich wrote:
iFCP frames can land anywhere in a TCP segment, i.e., it doesn’t have to
start at the beginning. There can be more than one iFCP frame in a
segment or only a portion of one. This may explain why there are so
many frames that are not decoded properly. The decoder needs to scan
the TCP segment for iFCP headers. This is not a tough thing to do;
generally speaking, I can’t speak for Ethereal decodes. The way it is
scanned is to look for the fields in the header and the corresponding
1’s complement fields. The CRC can be used to further check for the
proper parsing. Remember there is no one-to-one relationship between
iFCP frames and TCP segments. The TCP segments are transporting a byte
stream made of arbitrarily positioned iFCP frames.
FCP commands may be sent independently. When an entire segment can’t be
filled, data will not be kept waiting and is sent immediately. This may
change the positioning of iFCP frames.
Before a proper trace of FCP commands can be obtained, the decode must
have the ability to parse iFCP frames from the TCP segments, no matter
how many may be in the segment. Part of one, sometimes one, more than
one (jumbo frames).
There already appears to be code in the iFCP dissector to handle that.
Do you have an example of a capture where that code isn't working?
*From:* Valappil, Aboo
*Sent:* Monday, 27 June 2005 8:03 AM
*To:* Sahlberg, Ronnie; Schorr, Frank; Hinkle, Jack; Martin,
Kristen; Howard, Nigel; OConnor, Patrick; Covey, Kenneth
*Cc:* Hawley, Mike (APJK)
*Subject:* RE: Proprietary FC header - Ethereal helper, please check
this out.
We probably do not want to know what is in those 8 bytes, but that
is confusing ethereal and showing the incorrect fibre channel
header. I am wondering if ethereal has got plan to support this
Cisco EISL header ?
There really aren't any collective plans to support any particular
dissection. Some developer, whether they're part of the Ethereal core
team or not, might plan to add that support - but they'd probably need
some idea how to determine whether that extra header is present to add
that support (and some idea of what's in it in order to dissect it as
more than just 8 bytes of data).
Subject:
RE: iFCP support for Ethereal
From:
"Mark Detrick" <Mark.Detrick@xxxxxxxxxx>
Date:
Fri, 5 Aug 2005 15:12:34 -0600
To:
"Joshua Oelrich" <Josh.Oelrich@xxxxxxxxxx>, "Raj Rami" <Raj.Rami@xxxxxxxxxx>
To:
"Joshua Oelrich" <Josh.Oelrich@xxxxxxxxxx>, "Raj Rami" <Raj.Rami@xxxxxxxxxx>
CC:
"forum-ips" <forum-ips@xxxxxxxxxx>
Josh,
The decode for iFCP seems to be somewhat incomplete or not working
properly. There are too many packets with the status “Unreassembled”.
Can you get an explanation from the folks that sent this to you as to why?
Perhaps it's because the TCP preference enabling reassembly of data
isn't turned on?