ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] New Protocol encapsulation as plugin

Date: Thu, 4 Feb 2021 16:14:44 +0100
Hello all together,

thank you all for you suggestions how to solve my problem. I tried it this week to implement and i was able to fix my problem with the encapsulation type. Especially thanks to Guy Harris for answering my other questions, e.g. compiled plugins with binary packages.

Best regards,

Björn Petersen


Am 28.01.21 um 04:08 schrieb Guy Harris:
On Jan 27, 2021, at 3:16 AM, Björn <bjoern.petersen@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

we use a custom dissector to analyze custom protocol traffic. However, to further increase the usability, we need to add protocol analysis specific GUI elements. For now, we are not aware of a way to add a first level plugin which can be called through an encapsulation type from a pcap file.
Encapsulation types in pcap and pcapng files must be one of the already-registered types, meaning you would either have to

	1) request an official type by asking tcpdump-workers@xxxxxxxxxxxxxxxxx

or

	2) using one of the LINKTYPE_USERn types mentioned in other emails.

One other point is that we are not able to load a compiled plugin to wireshark, if we don’t build it from source. We can’t link against wireshark and cmake will not load the project if we install wireshark from the APT packages.
Not every instance of Wireshark is from an APT package:

	1) it might be Wireshark on Windows;

	2) it might be Wireshark on macOS;

	3) it might be Wireshark on *BSD;

	4) it might be Wireshark on Solaris;

		...

	n) it might be Wireshark on a Linux distribution that doesn't use Debian packages.

You could, however, have a Lua plugin, which should work on *any* platform if the version of Wireshark being used includes the embedded Lua interpreter (which our versions for Windows and macOS do, and which I suspect the packages provided by Linux distributions, *BSDs, etc. do).

	• We noticed that distributed packets, e.g. in Ubuntu 18.04 do not allow for C plugins to be loaded.
[citation needed]

	ubu20-04$ egrep DISTRIB_DESCRIPTION /etc/lsb-release
	DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
	ubu20-04$ apt list wireshark
	Listing... Done
	wireshark/focal,now 3.2.3-1 amd64 [installed,automatic]
	ubu20-04$ which tshark
	/bin/tshark
	ubu20-04$ tshark -G plugins
	ethercat.so     	0.1.0	dissector	/usr/lib/x86_64-linux-gnu/wireshark/plugins/3.2/epan/ethercat.so
	gryphon.so      	0.0.4	dissector	/usr/lib/x86_64-linux-gnu/wireshark/plugins/3.2/epan/gryphon.so
	irda.so         	0.0.6	dissector	/usr/lib/x86_64-linux-gnu/wireshark/plugins/3.2/epan/irda.so

		...

It appears to be loading the plugins we ship with Wireshark....

Our goal is creating an open source tool to analyze communication within SoCs, e.g. SoC FPGAs by providing both insight into protocol structure as well as bit and timing accurate analysis at the same time with cross-references.
2) will not be the best way to do that, because you don't have exclusive use of any of the USERn types - somebody else might use the same type, meaning users will have to configure their Wireshark to use yours or theirs.

You may think about this like an analyzer for video data transport protocols, which provides the ability to cross-reference actual pixels within the frames to the protocol entities that has contained them by showing the picture and enables clicking through the pixels / areas of the frames and the frames within the timeline of the video. When you click on an images pixel/area, the respective protocol unit containing the pixel is highlighted and vice versa. This allows for much better interpretation than going through the payload view or the image separately.
That requires more than a dissector, it requires a tap, with the GUI to display the video frame being able to look up the packet number in the packet list for the packet containing that pixel, and telling the Wireshark GUI to display that packet.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe