On Oct 29, 2003, at 5:10 PM, Dinesh G Dutt wrote:
I'm attaching a tar file to this email that contains:
- Dissector for FICON
- Dissector for FC-SP (Security Protocol for Fibre Channel)
- Patches to correct the reassembly of FC fragments.
- Support for new MDS Port Analyzer Adapters that carry the frame
length
for truncated frames.
...and doesn't contain
- a patch to define FC_TYPE_SB_FROM_CU, FC_TYPE_SB_TO_CU, or
FC_FTYPE_SBCCS.
However, the first two are defined by the FC-SB-3 spec, a draft of
which is available from the TC T11 Web site (which I have bookmarked),
and the third of those is, it appears, in a number space internal to
Ethereal, so I could just assign the next available value:
Index: packet-fc.h
===================================================================
RCS file: /cvsroot/ethereal/packet-fc.h,v
retrieving revision 1.4
diff -c -r1.4 packet-fc.h
*** packet-fc.h 23 Aug 2003 13:35:05 -0000 1.4
--- packet-fc.h 30 Oct 2003 01:56:25 -0000
***************
*** 45,50 ****
--- 45,52 ----
#define FC_TYPE_LLCSNAP 0x4
#define FC_TYPE_IP 0x5
#define FC_TYPE_SCSI 0x8
+ #define FC_TYPE_SB_TO_CU 0x1B
+ #define FC_TYPE_SB_FROM_CU 0x1C
#define FC_TYPE_FCCT 0x20
#define FC_TYPE_SWILS 0x22
#define FC_TYPE_AL 0x23
***************
*** 74,79 ****
--- 76,82 ----
#define FC_FTYPE_VDO 0x9
#define FC_FTYPE_LINKCTL 0xA
#define FC_FTYPE_SWILS_RSP 0xB
+ #define FC_FTYPE_SBCCS 0xC
/* Well-known Address Definitions (in Network order) */
#define FC_WKA_MULTICAST 0xFFFFF5
(Single-Byte Commands, channels, control units - that's gotta be FICON.
Is the next step to have the SNA dissector register with it? IBM
presumably has some SNA-over-channel transport....)
I've checked that in, along with your changes - send me an update if I
got it wrong (e.g., got the FC_TYPE values backwards).
BTW, "tvb_set_reported_length()" throws an exception if you try to make
the reported length *greater* than the existing value. I think that'd
mean that any truncated frame wouldn't get dissected past the Boardwalk
header; have you seen that? If so, perhaps we need a
"tvb_set_reported_len_greater()" routine (and document it as a "you
probably don't want to use this" routine, although the whole issue of
packet lengths in tvbuffs needs some cleaning up).