[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

see comments inline

On 8/11/05, Joshua Oelrich  wrote:
>  
> ---------- Forwarded message ----------
> From: "Mark Detrick" 
> Subject: RE: iFCP support for Ethereal
> More about the iFCP decodes for Ethereal… 
> 
> 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. 
> 

Ethereal should already handle these cases properly.
PDUs not aligned to the start of TCP segments   or PDUs spanning
multiple (partial) segments   or multiple PDUs inside one single
segment   is something we encounter for
all protocols transported atop TCP  which is why we have the TCP layer
emulate sliding windows and automatically track PDU boundaries.
I.e. we have this feature by nessecity to support all other protocols
so iFCP got it automatically.

The (very few) iFCP traces I have do decode iFCP frames starting
somewhere inside a TCP segment fine, it also handles multiple iFCP
PDUs inside a single segment as well.


If you have captures where this does not work, can you please send it
to the list, or if the captures contain sensitive data to me
personally either at this email address (preferrably) or my emc
address in the email train in your original message.
Then i will fix those bugs.


> 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. 

Ethereal is aware of TCP sliding windows and this will not pose a problem.
However, by default  Ethereal will only decode whatever data it finds
in one such "short" segment containing an incomplete iFCP (or other)
PDU.
Since Ethereal "knows" the PDU is short   it prints the text
[Unreassembled packet] or similar   to indicate there isnt really
anything wrong with the packet,   it is just
that the frame does not contain the full PDU.

This happens for example if the PDU spans multiple segments,   or if
you capture with a snaplen less than the ethernet frame size.


> 
> 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). 

It already does this.


Ethereal CAN reassemble iFCP PDUs spanning multiple segments  but this
is as for all other protocols off by default  since it elevates the
memory requirements.

To enable Ethereal to reassemble iFCP packets spanning multiple
segments and display the decode of the full reassembled PDU  :
Enable the following two options in the preferences :
Menu:/Edit/Preferences/Protocols/iFCP/Reassemble iFCP messages ...
Menu:/Edit/Preferences/Protocols/TCP/Allow subdissectors to reassemble
TCP streams



===
The only iFCP issue i am aware of is that when FC ELS is transported
ontop of iFCP,  the RXID values are   (for some implementations)
semi-random and can thus not be used when matching requests with
replies,   this is why for some implementations  you cant se the LOGI
responses proeprly.
I know what the issue is with ELS request/response matching failing
when FC ELS is used with iFCP (it works fine for FCIP and for "real"
fibrechannel) and why it fails,
it would be easily fixed by replacing the RXID in teh matching with
the TCP port numbers for the TCP session    but since I dont use iFCP
that much myself   and  even when I do   I ususally dont care about
the FC ELS protocol   I havent got round to fix it.

Note   this flaw only affects request response matching for FC ELS,  
normal frames carrying SCSI is completely unaffected and request
response matching works just fine.



Please send example captures with problems to me and ill fix them.
Also if you do have access to mFCP traces i would like to add support
for them as well.