On Jun 19, 2009, at 3:13 PM, kahou lei wrote:
> My fibre channel captured is in pcap format.
To use pcap format for a capture, either
1) your capture must be able to use an existing DLT_ value - which
isn't the case for Fibre Channel;
2) you use one of the DLT_USERn link-layer types;
3) you get a new DLT_ value assigned to you, and use that;
4) you are incorrectly using pcap format.
> What I want to do is to dissect this file with fibre channel
> dissector. In this case, do I still need to write code to read/write
> the file?
If you used one of the DLT_USERn values, then the code that reads pcap
files (and the code that reads pcap-ng files) will map those to
WTAP_ENCAP_USERn values (DLT_USER0 = 147 gets mapped to
WTAP_ENCAP_USER0, DLT_USER1 = 148 gets mapped to WTAP_ENCAP_USER1, and
so on through DLT_USER15 = 162 which gets mapped to WTAP_ENCAP_USER15).
You would open the Edit -> Preferences dialog, open up the list of
protocols, select the DLT_USER protocol, and click the "Edit" button.
That will pop up a dialog with a list of mappings from DLT_USER values
to protocols; click the "New" button, which will pop up another
dialog. Select the appropriate "User DLT" value (from 0 to 15) in the
first entry, put "fc" in as the protocol name, and click "OK". Then
click "OK" in the "User DLTs" dialog. That should now set up the
particular WTAP_ENCAP_USERn value, and thus the appropriate DLT_USERn
value in pcap and pcap-ng files, to be dissected as Fibre Channel
traffic.
(If it doesn't dissect it *correctly*, then you might have to add a
new dissector to, for example deal with any pseudo-headers you're
writing in front of the Fibre Channel header.)
That requires no changes to Wireshark (unless you'd need to handle
pseudo-headers, etc.). However, as you're using one of the "user-
defined" DLT_ values, somebody at another location - including any of
the Wireshark developers - will not be able to read your capture
without doing the same configuration, and they might be using that
DLT_ value at their site for some other purpose and thus might not
want to have to temporarily reconfigure Wireshark to interpret that
DLT_ value as Fibre Channel.
If you have gotten a new DLT_ value from tcpdump.org, then you would
have to:
add a WTAP_ENCAP_FIBRE_CHANNEL value to the list of WTAP_ENCAP_
values in wiretap/wtap.h;
add an entry for WTAP_ENCAP_FIBRE_CHANNEL to the encap_table_base
table in wiretap/wtap.c;
have the proto_reg_handoff_fc() routine in epan/dissectors/packet-
fc.c do:
dissector_add("wtap_encap", WTAP_ENCAP_FIBRE_CHANNEL,
find_dissector
("fc"));
This requires some changes to Wireshark, but, once it's done, there's
now a standard for Fibre Channel pcap and pcap-ng files, and, if you
send us the changes and we add them to Wireshark, people with the
newer version of Wireshark will be able to read your files without
doing any configuration.
If you just chose some random number as the DLT_ value, then there
might be a good chance that, in some future Wireshark release, that
number will be interpreted as some other type of capture, and that
Wireshark release won't read your files the way you would want it to
without having to modify it. We very strongly suggest that nobody do
that.
> Or just create a new DLT value for Fibre Channel and then register
> the existing fibre channel dissector with it?
The only parts of Wireshark that knows about DLT_ values are:
the code that reads pcap and pcap-ng files;
the code that implements the preferences for the DLT_USER protocol
(and that doesn't know very much about them).
Wireshark reads more than just pcap and pcap-ng files, so, internally,
it has its own values for packet encapsulation types, which are
different from the DLT_ values (and, in fact, some correspond to
encapsulation types for which there currently *are* no DLT_ values).
That's why, once you get a new DLT_ value assigned for Fibre Channel,
you have to do the steps listed above in the "If you have gotten a new
DLT_ value from tcpdump.org" section.
To request a new DLT_ value, send a message to tcpdump-work...@tcpdump.org
.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
