Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] rs232 dissection?

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 10 Feb 2012 13:10:20 -0800
On Feb 10, 2012, at 12:38 PM, eymanm wrote:

> I'm looking into using wireshark to dissect rs232 trafic. No Ethernet. Data is organised in 64-bit packets. Can somebody weigh if this is doable, and if so, suggest a brief implementation plan?

As long as the 64-bit packets are written in a file format that Wireshark can understand, it should be possible to make Wireshark dissect the packets.

To *capture* the packets in Wireshark would require some more work.

As for the file format, you could:

	use one of the USERn link-layer type values in a pcap or pcap-NG file, and set up your dissector to handle that USERn type;

	get a link-layer header type value officially assigned, by sending a request to tcpdump-workers@xxxxxxxxxxxxxxxxx (and supplying a description of the packet format or a link to that specification), use it in a pcap or pcap-NG file, add a WTAP_ENCAP_ value for your packets, and modify Wireshark to map that link-layer header type value to the WTAP_ENCAP_ value, and have your dissector register for that WTAP_ENCAP_ value;

	use your own file format, add a WTAP_ENCAP_ value for your packets, add code to read that file format using that WTAP_ENCAP_ value,  and modify Wireshark to map that link-layer header type value to the WTAP_ENCAP_ value, and have your dissector register for that WTAP_ENCAP_ value.

The first of those minimizes the number of changes to Wireshark, but means that the support for your protocol cannot be enabled by default in an official Wireshark release (Wireshark deliberately *avoids* wiring the WTAP_ENCAP_USERn values to any protocol, so that users are free to use them as they choose), and means there's no guarantee that your files will be readable by default in anybody else's Wireshark.

The second of those requires more work than the first but less work than the third, and means that the support for your protocol can be enabled by default in an official Wireshark release.

The third of those requires additional work.

I'd recommend the first or second - the first if you're only using it yourself, the second if you want to exchange captures with other people.