The get_ifcp_pdu_len() call used for the tcp_dissect_pdus() call does not mask
off the frame length properly. The result is that the "Flags" field
incorrectly becomes the high order part of the Frame Length.
svn path=/trunk/; revision=25416
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
there are many reasons why some protocols actually need to be able to access the pinfo structure while determining the pdu size
svn path=/trunk/; revision=19751
remove the port preference setting and replace it with strong heuristics instead
(attempt but fail to set a conversation dissector when the heuristics and the dissection match)
use tcp_dissect_pdus() for reassembly and pdu tracking and get rid of the try-to-step-through-the-pdu-to-find-where-the-next-pdu-starts thing.
svn path=/trunk/; revision=17804
The FC D_id and S_id fields in teh FC frame encapsulated inside iFCP unfortunately has "undefined" (semi-random) values so we can not use th S_/D_id matching in FC when transported atop iFCP.
Change iFCP to call a new fc_ifcp handler instead of the fc handler.
Add a new handler to FC specific to iFCP.
Only set the pinfo->src/dst fields to the S_id/D_id fields IFF the FC frame was NOT transported ontop of iFCP.
Othervise we just use the TCP/IP values that are already stored there.
Some Hosts use RelativeOffset fields for FC. We can only dissect the RelOff field with offset 0.
Change FC to only call the FCP subdissector if offset==0 when relative offsets are used.
Some hosts when using relative offsets do not specify a proper value for rxid in teh commands instead htey lkeave it as 0xffff
Change the FCP conversation matching to ignore RXID when searching for a conversation.
svn path=/trunk/; revision=15076
Bill Meier