This is a static archive of our old Q&A Site. Please post any new questions and answers at

Registering a dissector for a third party protocol



I'd like to create a dissector for an in-house "foo" protocol for which I have some PCAP formatted files.

The Data Link Type for now is DLT_USER0 (147), but in the future it may be something else.

For now I just want to dissect the protocol using this DLT.

What I succeeded to do is to write my dissector as a plugin and in Edit - Preferences - Protocol - DLT_USER I added a line that specifies that for User 0 (DLT=147) the Payload Protocol is foo.

In order for my dissector to be recognized in the Payload protocol column I had to add the following call in my dissector:

new_register_dissector("foo", dissect_foo, proto_foo);

I found this by looking at other dissectors, but I cannot find any official docs on the new_register_dissector function, only some vague info on register_dissector in README.dissector.

Q1: Where can I find some docs about this?

This successfully runs my foo dissector on those pcap files although in the dissector I'm using (from the examples): dissector_add_uint("tcp.port", 0, foo_handle);

Q2: Why does this work since the dissector table specified by me in the plugin is tc.port? Or does wireshark match the first true condition, either from the interface or from the dissector itself?

Q3: Is there a dissector table for PCAP files with a specific DLT?

I saw in the Supported protocol window that there is the pcap protocol and I tried this: dissector_add_uint("pcap.header.link_type", 147, foo_handle);

But when I start wireshark I get the following error:

OOPS: dissector table "pcap.header.link_type" doesn't exist
Protocol being registered is "foo long name"

asked 25 Dec '15, 03:05

paulbarbu's gravatar image

accept rate: 0%

I'm not a core developer so I don't dare to place it as an Answer, but I can see something inconsistent in what you do. Think about protocols as about a tree where the link encapsulation is the base of the trunk. So if your dissector forms up a branch od the tree growing from point "tcp port xyz", it cannot at the same time grow from the ground (user encapsulation) directly.


  • either a frame uses encapsulation (data link type) 147, and in that case, dissection starts from the Payload protocol registered for DLT 147 (which is foo). In such case, there is no TCP in that frame (well, at least unless foo is able to encapsulate TCP), so the fact that foo is a dissector for tcp port xyz is irrelevant for that frame,

  • or a frame uses some standard encapsulation (ethernet), so setting of foo as Payload protocol for DLT 147 is irrelevant for that frame, and in that case, the frame may contain all the layers between ethernet and tcp, so the foo dissector kicks in if the tcp port matches xyz.

I.e. you may specify both triggers, but only one of them will be used in a single frame. If you only need one, it is pointless to define the other one.

(25 Dec '15, 03:44) sindy

Ok, this answers Q2, which is kind of intuitive and I expected this. I'd still like some docs on the new_register_dissector function and whether I can skip the step where I manually add the dissector in the user interface for my DLT.

(25 Dec '15, 04:45) paulbarbu

Again, I am not a core developer, but I'm afraid that the user DLTs are intended for dynamic assignment, i.e. that the mapping between a given user DLT and ground-level dissector may be (and should be) stored in your user profile but there is (intentionally) no way to let the dissector hook to that DLT directly.

(25 Dec '15, 04:56) sindy

That seems pretty resonable since otherwise dissectors may be distributed with those user defined DLTs. Thank you for your comments. Do you have any idea where can I get the docs for new_register_dissector? (I haven't looked yet in the code)

(25 Dec '15, 05:01) paulbarbu

I'm afraid that your alternative to reading the code is to wait for a core developer to come and shed some light. My bet is that the documentation doesn't exist (yet, of course ;-) ) on the grounds that whoever for whom it is useful can find sufficient information in the code and whoever doesn't understand it from the code should not tamper with registering a dissector :-)

(25 Dec '15, 05:54) sindy

Ok, I understand your point, but how can one know about this functionality, how does one get to know they need to use this function? I had luck finding something about this in other answers...

(25 Dec '15, 06:02) paulbarbu

To my experience, this is how things work with opensource. So when you want to write your own dissector, you take someone else's one, and replace its guts with your own. This process gives you a fair amount of information about how things are done.

It needs a special kind of person to prefer to spend their spare time writing documentation against spending it to make some piece of code work (or work even better). Lua dissection is a bit different story because it is targeted to people who aren't familiar with the inside enough, and the API is written in a different language than Lua, so the documentation is necessary for the idea to work.

(25 Dec '15, 06:17) sindy

I'll respectively disagree with @sindy regarding Wireshark documentation.

For Wireshark development we have straight off the front page of the web site (using the Develop -> Get Involved link) the develop page, which amongst other resources, lists the Developers Guide and the Development page on the wiki. The wiki page lists README.developer which can also be found in the doc directory of the sources, which includes the most important for devs (IMHO) README.dissector.

As always, any of this documentation can be updated and amended by the users, either directly on the wiki, via a patch for the files in the source tree, or by a notification to the developers for the web site.

(25 Dec '15, 08:18) grahamb ♦

I'm afraid there isn't enough ash available to pour over my head. While writing that, I had in mind that the documentation is usually several steps behind the development, not that the documentation does not exist at all, but haven't written that clearly. Sorry for that.

(25 Dec '15, 13:25) sindy

@sindy, no need for the ash, in the spirit of the festive season good will to all.

(25 Dec '15, 15:13) grahamb ♦
showing 5 of 10 show 5 more comments

One Answer:


Is there a dissector table for PCAP files with a specific DLT?


There is a dissector table for particular libwiretap packet encapsulations - "wtap_encap".

The libwiretap encapsulations for the pcap/pcapng DLT_USER0/LINKTYPE_USER0 through DLT_USER15/LINKTYPE_USER15 link-layer header types are, respectively, WTAP_ENCAP_USER0 through WTAP_ENCAP_USER15.

So you want

dissector_add_uint("wtap_encap", WTAP_ENCAP_USER0, foo_handle);

answered 25 Dec '15, 14:10

Guy%20Harris's gravatar image

Guy Harris ♦♦
accept rate: 19%