From Frank Schorr:

RFC 4172 section 5.3.1 shows a chart of the iFCP encapsulated Header Format.
It says that bytes 4-7 MUST be zeros.  In reality most vendors are putting some
information in these 4 bytes, particularly Nishon. This caused almost all iFCP
packets to not be decoded for this vendor.

svn path=/trunk/; revision=25415
This commit is contained in:
Jaap Keuter 2008-06-03 20:41:12 +00:00
parent 2640b786f4
commit c47e8dab0c
1 changed files with 7 additions and 4 deletions

View File

@ -106,9 +106,12 @@ static const value_string fcencap_proto_vals[] = {
{0, NULL},
};
static const guint8 ifcp_header_8_bytes[8] = {
0x02, 0x01, 0xFD, 0xFE,
0x00, 0x00, 0x00, 0x00
/* RFC 4172 section 5.3.1 shows a chart of the iFCP encapsulated Header Format.
* It says that bytes 4-7 MUST be zeros. In reality most vendors are putting
* some information in these 4 bytes, particularly Nishon.
*/
static const guint8 ifcp_header_4_bytes[4] = {
0x02, 0x01, 0xFD, 0xFE
};
static int proto_ifcp = -1;
@ -202,7 +205,7 @@ ifcp_header_test(tvbuff_t *tvb, int offset)
/*
* Tests a, b and c
*/
if(tvb_memeql(tvb, offset, ifcp_header_8_bytes, 8) != 0){
if(tvb_memeql(tvb, offset, ifcp_header_4_bytes, 4) != 0){
return FALSE;
}