Hello, 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 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 In order for my dissector to be recognized in the
I found this by looking at other dissectors, but I cannot find any official docs on the Q1: Where can I find some docs about this? This successfully runs my Q2: Why does this work since the dissector table specified by me in the plugin is Q3: Is there a dissector table for PCAP files with a specific DLT? I saw in the But when I start wireshark I get the following error: asked 25 Dec '15, 03:05  paulbarbu showing 5 of 10 show 5 more comments |
One Answer:
No. There is a dissector table for particular libwiretap packet encapsulations - The libwiretap encapsulations for the pcap/pcapng So you want answered 25 Dec '15, 14:10  Guy Harris ♦♦ |
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.
So
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.
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.
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.
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)
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 :-)
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...
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.
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.
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.
@sindy, no need for the ash, in the spirit of the festive season good will to all.