Ethereal-users: [Ethereal-users] Suggestions for iFCP filtering in Ethereal.

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: "Joshua Oelrich" <Josh.Oelrich@xxxxxxxxxx>
Date: Wed, 10 Aug 2005 14:18:21 -0600
Title: Suggestions for iFCP filtering in Ethereal.

<<RE: iFCP support for Ethereal >> <<RE: iFCP support for Ethereal >>

__________________________________________________
Josh Oelrich
Sr. System Engineer
McDATA Corporation
Office: (720) 558-3530
Mobile: (303) 913-4722
Email: josh.oelrich@xxxxxxxxxx
Support Hotline: (800) 752-4572
__________________________________________________

SPECIAL NOTICE

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies. To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)
--- Begin Message ---
From: "Mark Detrick" <Mark.Detrick@xxxxxxxxxx>
Date: Fri, 5 Aug 2005 16:00:59 -0600
Title: Message

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.

 

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

 

Josh please forward this onto the authors of the Ethereal decode.

 

Thanks,

Mark S. Detrick, CCIE 6336 | Systems Architect, SAN Routing & Extension

503.645.2488 o | 503.936.4137 c | 503.629.4902 f

McDATA Solutions & Technologies Group | mark.detrick@xxxxxxxxxx

From: Joshua Oelrich
Sent: Wednesday, July 20, 2005 8:49 AM
To: Raj Rami
Cc: forum-ips
Subject: FW: iFCP support for Ethereal

 

Good stuff!

 

__________________________________________________
Josh Oelrich
Sr. System Engineer
McDATA Corporation
Office: (720) 558-3530
Mobile: (303) 913-4722
Email: josh.oelrich@xxxxxxxxxx
Support Hotline: (800) 752-4572
__________________________________________________

 

 

From: Bentley_Bill@xxxxxxx [mailto:Bentley_Bill@xxxxxxx]
Sent: Wednesday, July 20, 2005 6:01 AM
To: Joshua Oelrich
Subject: FW: iFCP support for Ethereal

You may find this useful.

Bill

 

 

From: Martin, Kristen
Sent: Wednesday, July 20, 2005 2:20 AM
To: Bentley, Bill
Subject: FW: iFCP support for Ethereal

FYI

 

From: Valappil, Aboo
Sent: 20 July 2005 00:31
To: GNS
Cc: Sahlberg, Ronnie; Hawley, Mike (APJK)
Subject: iFCP support for Ethereal

Hi All,

 

I remember the grief in Jack’s training everyone had when we realized that ethereal could not do iFCP. Enjoy now ….

 

iFCP support for ethereal has been implemented. Please download the latest ( Any SVN version above 14957). You can download it from the following site.

 

http://www.ethereal.com/distribution/buildbot-builds/

 

Thanks

 

Aboo

Thanks to Ronnie in helping out to get this done !!!

From: Sahlberg, Ronnie
Sent: Tuesday, June 28, 2005 8:22 AM
To: Valappil, Aboo; Schorr, Frank; Hinkle, Jack
Subject: RE: Proprietary FC header - Ethereal helper, please check this out.

 

So let us get iFCP also working then .... If you let me do it, I will try to get that going.

 

    sure,    just send me a patch when you are finished and i will check it in.

    also provide what email address you want listed in the AUTHORS file

 

-----Original Message-----
From: Valappil, Aboo
Sent: Tuesday, 28 June 2005 12:00 AM
To: Valappil, Aboo; 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.

Oh man ... It is really obsolete L

I tried it the new ethereal and it works.

 

My tool goes to the thrash. L Bummer.

 

So let us get iFCP also working then .... If you let me do it, I will try to get that going.

 

Aboo

 

 

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.

 

That is great !

 

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 ?

 

Till that time, I guess we can use my tool to move those 8 bytes away from the FC header.

 

Aboo

 

 

From: Sahlberg, Ronnie
Sent: Monday, 27 June 2005 4:40 AM
To: Valappil, Aboo; 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.

 

A new version/pre-release of ethereal should be available in approx one hour at

 

Use the windows installer with SVN version 14796 or later.

 

SVN version 14796 or later of ethereal will decode these packets just fine.   sorry aboo    your tool is pretty much obsolete now :-)   hope you didnt spend too much time on it :-D

 

 

 

 

I got a response from Dinesh(their fibrechannel guy) as well and those 8 mysterious bytes are just the same (proprietary) EISL header that they use for normal fibrechannel as well.

He did not know if they have officially release the spec of the EISL header yet or not   so ethereal will not decode them, just show them as

some unknown EISL blob.

I do not think we need to know the content of those bytes anyway.

 

 

 

 

 

-----Original Message-----
From: Valappil, Aboo
Sent: Monday, 27 June 2005 12:36 PM
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.

Ronnie,

 

Thanks for the information.

 

Also, Cisco does not follow the FC standard  between their switches. Over local ISL or ISL over FCIP. They throw this 8 bytes extra before the actual FC protocol starts. One could think that ethereal and other softwares just following the standards and not decoding the packet properly. But once we move this 8 bytes some where we get a good FC encapsulation. (At least we follow a conversation/SCSI command  with SID, DID, Sequence numbers, OXID, etc ... )

 

Cisco is using this 8 bytes for putting some VSAN related information. I do not know exactly the format they follow, May be Jack might be able to throw some light on this.

 

Aboo

 

 

From: Sahlberg, Ronnie
Sent: Sunday, 26 June 2005 8:36 PM
To: Valappil, Aboo; 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.

 

Ethereal does not recognize those packets as FCIP for the simple reason :

these are NOT fcip packets!

 

Whatever the packets are,  how similar they might be to fcip   they are not fcip.

 

 

RFC for FCIP

 

See section  7.1  which describes the packet format,

CRC is always 0  for FCIP.

 

See section 5.6.2.2  that describes a test that a FCIP MUST implement in order to accept or discard an incoming packet.

Test f :  is a fcip MUST verify that CRC is 0   or else it is not FCIP.

 

 

Ethereal follows the RFC and discards the packets since they are invalid frames.

 

When i get home tonight i will change this so that ethereal will allow   non-RFC compliant uses of CRC  and add a comment to the code on why

ethereal no longer follows the standard when performing the test.

 

 

Thanks for the pointer aboo.    maybe they implement a pre-RFC draft of fcip which does not mandate that crc must be 0?

 

 

-----Original Message-----
From: Valappil, Aboo
Sent: Monday, 27 June 2005 5:57 AM
To: Schorr, Frank; Hinkle, Jack; Martin, Kristen; Howard, Nigel; OConnor, Patrick; Covey, Kenneth; Valappil, Aboo
Cc: Sahlberg, Ronnie; Hawley, Mike (APJK)
Subject: Proprietary FC header - Ethereal helper, please check this out.

Hi All,

 

I made this little tool which fix two issues we have encountered with analysing FCIP traces with ethereal.

 

  1. Due some reason ( I think it is  a bug in ethereal ), ethereal would not decode the FCIP/FC frames if there is a FCIP CRC present which is not non zero. This tool should search through and make the CRC's 0 so that ethereal can decode it properly.

 

  1. This is about Cisco's proprietary header in the FC channel header.  The tool search Cisco proprietary FC header in the FC header, move off the 8 bytes to end of the FC payload after the FC CRC (May be I should move it before the CRC, anyway ethereal does not seems to care about it). The way tool finds the Cisco proprietary header is by looking at the cs_ctl field. If it is not 0, it is a Cisco stuff. Is this ok ? Or the tool will get cheated by looking at the cs_ctl field ?

 

As per the design, the frame should be untouched if it is not FCIP frame.  It should not touch the FC header if it is a normal FC frame (No Cisco). It will change the FCIP CRC to 0 for all the FCIP frames. I also included support for multiple FCIP payloads in a single TCP segment (I did not test this because I do not have a capture with this).

 

Attached is the exe file. As usual, rename to .exe to run.  I also attached a FCIP libpcap capture to test the tool out. Run the tool on the attached capture file, open both traces after running the tool in ethereal and you can feel the difference.

 

Usage is ...

 

fcip_helper  <input file> <output file>

 

It should not modify anything in the input file, but create a output file with modifications.

 

This is just an attempt, I like to improve on this tool so that it can be used bug free ! Your evaluation, suggestions and help is very much required to improve this. It seems to be working so far ...

 

This tool only works with the libpcap capture files. If you have finisar trace, you need to convert that to a surveyor format. Open it in ethereal and save it as a libpcap format. Then you can use the tool.  I wish I could have done this on the Finisar trace directly, but I do not know the format.

 

I will also talk to Ronnie about iFCP support of ethereal. May be we can do something about it.

 

Thanks

 

Aboo

 

 

 

 

 

From: Schorr, Frank
Sent: Thursday, 23 June 2005 2:09 PM
To: Hinkle, Jack; Martin, Kristen; Howard, Nigel; OConnor, Patrick; Covey, Kenneth; Valappil, Aboo
Subject: RE: Proprietary FC header

 

 

 

From: Hinkle, Jack
Sent: Thursday, June 23, 2005 1:39 PM
To: Martin, Kristen; Howard, Nigel; Schorr, Frank; OConnor, Patrick; Covey, Kenneth; Valappil, Aboo
Subject: FW: Proprietary FC header

 

 

 

From: Jordan Carroll [mailto:jordan.carroll@xxxxxxxxxxx]
Sent: Tuesday, May 24, 2005 11:25 AM
To: Sara Haber; Hinkle_Jack@xxxxxxx
Subject: RE: Proprietary FC header

Hey Jack-

 

You can find the latest version of the PDK on our ftp site:

user:  public

password:  public

directory:  /Software/PDK

file:  PDK 1.1.zip

 

Please down load the file, then unzip and install on your PC which has the Xgig/GTX Trace View application.  Once installed you can get a complete user's guide under the "Help" and "Contents" menu.  Please review this first.  To create your customer decode you will modify the existing "CurrentProtocols.pmd" file.  (See Using the Graphical PDK chapter in the help guide)  Be sure to first create a backup of the current protocol just in case you make a mistake.  For example, create a CurrentProtocols.pmd.backup. 

One final note.  Although we do provide a Graphical Decode Kit for the end user, this product is not directly supported by engineering.  This was given to provide access to Finisar's decode, for example, if they wanted to create a proprietary protocol.  Thus please be aware of the changes you make.

 

Hope that helps.

 

Regards,

 

Jordan Carroll

Finisar, Support

(408) 400-1070

-----Original Message-----
From: Sara Haber
Sent: Monday, May 23, 2005 2:41 PM
To: 'Hinkle_Jack@xxxxxxx'
Cc: Jordan Carroll
Subject: RE: Proprietary FC header

Hi Jack,

 

We have a Protocol Editor that may be able to accomplish this.  I'll refer you to Jordan Carroll who is our in-house expert on the PDK.

 

Sara

 

Sara Haber
Director of Technical Resources
Network Tools Division
Finisar Corp
office phone:  408.542.4111
mobile phone: 415.378.9143
 
sara.haber@xxxxxxxxxxx
 

-----Original Message-----
From: Hinkle_Jack@xxxxxxx [mailto:Hinkle_Jack@xxxxxxx]
Sent: Monday, May 23, 2005 1:24 PM
To: Sara Haber
Subject: Proprietary FC header

 

Hi Sara,

 

We have an issue when analyzing Cisco switch ISL traffic. They put an 8 byte VLAN header in the beginning of the FC frame. this offsets the standard FC header which really screws up the the trace viewer interpretation. It also renders Expert pretty much useless. This is also done in their FCIP encapsulation frame.

 

I've attached Cisco's proposal to T11. R-CTL= 50 is currently used. F1 and F2 appear to be planned in the future.

 

Is there any way we can get a viewer to correctly interpret these frames?


--- End Message ---
--- Begin Message ---
From: "Mark Detrick" <Mark.Detrick@xxxxxxxxxx>
Date: Fri, 5 Aug 2005 15:12:34 -0600
Title: Message

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?

 

For everybody’s information, Ethereal relies on end users to provide decodes.  I was told by Cisco that the Andiamo group maintains the FC, FCIP, ISl & EISL decodes for Ethereal because they rely on Ethereal for their field and customers as part of the diagnostic features.  These decodes should have everything needed for Cisco.  I look and the EISL header is part of the FC protocol.

 

Thanks,

Mark S. Detrick, CCIE 6336 | Systems Architect, SAN Routing & Extension

503.645.2488 o | 503.936.4137 c | 503.629.4902 f

McDATA Solutions & Technologies Group | mark.detrick@xxxxxxxxxx

From: Joshua Oelrich
Sent: Wednesday, July 20, 2005 8:49 AM
To: Raj Rami
Cc: forum-ips
Subject: FW: iFCP support for Ethereal

 

Good stuff!

 

__________________________________________________
Josh Oelrich
Sr. System Engineer
McDATA Corporation
Office: (720) 558-3530
Mobile: (303) 913-4722
Email: josh.oelrich@xxxxxxxxxx
Support Hotline: (800) 752-4572
__________________________________________________

 

 

From: Bentley_Bill@xxxxxxx [mailto:Bentley_Bill@xxxxxxx]
Sent: Wednesday, July 20, 2005 6:01 AM
To: Joshua Oelrich
Subject: FW: iFCP support for Ethereal

You may find this useful.

Bill

 

 

From: Martin, Kristen
Sent: Wednesday, July 20, 2005 2:20 AM
To: Bentley, Bill
Subject: FW: iFCP support for Ethereal

FYI

 

From: Valappil, Aboo
Sent: 20 July 2005 00:31
To: GNS
Cc: Sahlberg, Ronnie; Hawley, Mike (APJK)
Subject: iFCP support for Ethereal

Hi All,

 

I remember the grief in Jack’s training everyone had when we realized that ethereal could not do iFCP. Enjoy now ….

 

iFCP support for ethereal has been implemented. Please download the latest ( Any SVN version above 14957). You can download it from the following site.

 

http://www.ethereal.com/distribution/buildbot-builds/

 

Thanks

 

Aboo

Thanks to Ronnie in helping out to get this done !!!

From: Sahlberg, Ronnie
Sent: Tuesday, June 28, 2005 8:22 AM
To: Valappil, Aboo; Schorr, Frank; Hinkle, Jack
Subject: RE: Proprietary FC header - Ethereal helper, please check this out.

 

So let us get iFCP also working then .... If you let me do it, I will try to get that going.

 

    sure,    just send me a patch when you are finished and i will check it in.

    also provide what email address you want listed in the AUTHORS file

 

-----Original Message-----
From: Valappil, Aboo
Sent: Tuesday, 28 June 2005 12:00 AM
To: Valappil, Aboo; 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.

Oh man ... It is really obsolete L

I tried it the new ethereal and it works.

 

My tool goes to the thrash. L Bummer.

 

So let us get iFCP also working then .... If you let me do it, I will try to get that going.

 

Aboo

 

 

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.

 

That is great !

 

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 ?

 

Till that time, I guess we can use my tool to move those 8 bytes away from the FC header.

 

Aboo

 

 

From: Sahlberg, Ronnie
Sent: Monday, 27 June 2005 4:40 AM
To: Valappil, Aboo; 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.

 

A new version/pre-release of ethereal should be available in approx one hour at

 

Use the windows installer with SVN version 14796 or later.

 

SVN version 14796 or later of ethereal will decode these packets just fine.   sorry aboo    your tool is pretty much obsolete now :-)   hope you didnt spend too much time on it :-D

 

 

 

 

I got a response from Dinesh(their fibrechannel guy) as well and those 8 mysterious bytes are just the same (proprietary) EISL header that they use for normal fibrechannel as well.

He did not know if they have officially release the spec of the EISL header yet or not   so ethereal will not decode them, just show them as

some unknown EISL blob.

I do not think we need to know the content of those bytes anyway.

 

 

 

 

 

-----Original Message-----
From: Valappil, Aboo
Sent: Monday, 27 June 2005 12:36 PM
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.

Ronnie,

 

Thanks for the information.

 

Also, Cisco does not follow the FC standard  between their switches. Over local ISL or ISL over FCIP. They throw this 8 bytes extra before the actual FC protocol starts. One could think that ethereal and other softwares just following the standards and not decoding the packet properly. But once we move this 8 bytes some where we get a good FC encapsulation. (At least we follow a conversation/SCSI command  with SID, DID, Sequence numbers, OXID, etc ... )

 

Cisco is using this 8 bytes for putting some VSAN related information. I do not know exactly the format they follow, May be Jack might be able to throw some light on this.

 

Aboo

 

 

From: Sahlberg, Ronnie
Sent: Sunday, 26 June 2005 8:36 PM
To: Valappil, Aboo; 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.

 

Ethereal does not recognize those packets as FCIP for the simple reason :

these are NOT fcip packets!

 

Whatever the packets are,  how similar they might be to fcip   they are not fcip.

 

 

RFC for FCIP

 

See section  7.1  which describes the packet format,

CRC is always 0  for FCIP.

 

See section 5.6.2.2  that describes a test that a FCIP MUST implement in order to accept or discard an incoming packet.

Test f :  is a fcip MUST verify that CRC is 0   or else it is not FCIP.

 

 

Ethereal follows the RFC and discards the packets since they are invalid frames.

 

When i get home tonight i will change this so that ethereal will allow   non-RFC compliant uses of CRC  and add a comment to the code on why

ethereal no longer follows the standard when performing the test.

 

 

Thanks for the pointer aboo.    maybe they implement a pre-RFC draft of fcip which does not mandate that crc must be 0?

 

 

-----Original Message-----
From: Valappil, Aboo
Sent: Monday, 27 June 2005 5:57 AM
To: Schorr, Frank; Hinkle, Jack; Martin, Kristen; Howard, Nigel; OConnor, Patrick; Covey, Kenneth; Valappil, Aboo
Cc: Sahlberg, Ronnie; Hawley, Mike (APJK)
Subject: Proprietary FC header - Ethereal helper, please check this out.

Hi All,

 

I made this little tool which fix two issues we have encountered with analysing FCIP traces with ethereal.

 

  1. Due some reason ( I think it is  a bug in ethereal ), ethereal would not decode the FCIP/FC frames if there is a FCIP CRC present which is not non zero. This tool should search through and make the CRC's 0 so that ethereal can decode it properly.

 

  1. This is about Cisco's proprietary header in the FC channel header.  The tool search Cisco proprietary FC header in the FC header, move off the 8 bytes to end of the FC payload after the FC CRC (May be I should move it before the CRC, anyway ethereal does not seems to care about it). The way tool finds the Cisco proprietary header is by looking at the cs_ctl field. If it is not 0, it is a Cisco stuff. Is this ok ? Or the tool will get cheated by looking at the cs_ctl field ?

 

As per the design, the frame should be untouched if it is not FCIP frame.  It should not touch the FC header if it is a normal FC frame (No Cisco). It will change the FCIP CRC to 0 for all the FCIP frames. I also included support for multiple FCIP payloads in a single TCP segment (I did not test this because I do not have a capture with this).

 

Attached is the exe file. As usual, rename to .exe to run.  I also attached a FCIP libpcap capture to test the tool out. Run the tool on the attached capture file, open both traces after running the tool in ethereal and you can feel the difference.

 

Usage is ...

 

fcip_helper  <input file> <output file>

 

It should not modify anything in the input file, but create a output file with modifications.

 

This is just an attempt, I like to improve on this tool so that it can be used bug free ! Your evaluation, suggestions and help is very much required to improve this. It seems to be working so far ...

 

This tool only works with the libpcap capture files. If you have finisar trace, you need to convert that to a surveyor format. Open it in ethereal and save it as a libpcap format. Then you can use the tool.  I wish I could have done this on the Finisar trace directly, but I do not know the format.

 

I will also talk to Ronnie about iFCP support of ethereal. May be we can do something about it.

 

Thanks

 

Aboo

 

 

 

 

 

From: Schorr, Frank
Sent: Thursday, 23 June 2005 2:09 PM
To: Hinkle, Jack; Martin, Kristen; Howard, Nigel; OConnor, Patrick; Covey, Kenneth; Valappil, Aboo
Subject: RE: Proprietary FC header

 

 

 

From: Hinkle, Jack
Sent: Thursday, June 23, 2005 1:39 PM
To: Martin, Kristen; Howard, Nigel; Schorr, Frank; OConnor, Patrick; Covey, Kenneth; Valappil, Aboo
Subject: FW: Proprietary FC header

 

 

 

From: Jordan Carroll [mailto:jordan.carroll@xxxxxxxxxxx]
Sent: Tuesday, May 24, 2005 11:25 AM
To: Sara Haber; Hinkle_Jack@xxxxxxx
Subject: RE: Proprietary FC header

Hey Jack-

 

You can find the latest version of the PDK on our ftp site:

user:  public

password:  public

directory:  /Software/PDK

file:  PDK 1.1.zip

 

Please down load the file, then unzip and install on your PC which has the Xgig/GTX Trace View application.  Once installed you can get a complete user's guide under the "Help" and "Contents" menu.  Please review this first.  To create your customer decode you will modify the existing "CurrentProtocols.pmd" file.  (See Using the Graphical PDK chapter in the help guide)  Be sure to first create a backup of the current protocol just in case you make a mistake.  For example, create a CurrentProtocols.pmd.backup. 

One final note.  Although we do provide a Graphical Decode Kit for the end user, this product is not directly supported by engineering.  This was given to provide access to Finisar's decode, for example, if they wanted to create a proprietary protocol.  Thus please be aware of the changes you make.

 

Hope that helps.

 

Regards,

 

Jordan Carroll

Finisar, Support

(408) 400-1070

-----Original Message-----
From: Sara Haber
Sent: Monday, May 23, 2005 2:41 PM
To: 'Hinkle_Jack@xxxxxxx'
Cc: Jordan Carroll
Subject: RE: Proprietary FC header

Hi Jack,

 

We have a Protocol Editor that may be able to accomplish this.  I'll refer you to Jordan Carroll who is our in-house expert on the PDK.

 

Sara

 

Sara Haber
Director of Technical Resources
Network Tools Division
Finisar Corp
office phone:  408.542.4111
mobile phone: 415.378.9143
 
sara.haber@xxxxxxxxxxx
 

-----Original Message-----
From: Hinkle_Jack@xxxxxxx [mailto:Hinkle_Jack@xxxxxxx]
Sent: Monday, May 23, 2005 1:24 PM
To: Sara Haber
Subject: Proprietary FC header

 

Hi Sara,

 

We have an issue when analyzing Cisco switch ISL traffic. They put an 8 byte VLAN header in the beginning of the FC frame. this offsets the standard FC header which really screws up the the trace viewer interpretation. It also renders Expert pretty much useless. This is also done in their FCIP encapsulation frame.

 

I've attached Cisco's proposal to T11. R-CTL= 50 is currently used. F1 and F2 appear to be planned in the future.

 

Is there any way we can get a viewer to correctly interpret these frames?


--- End Message ---