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


In a lab setup I need to analyze packets which headers are based on GRE but altered in the way that there are additional TLV-fields being added after the standard GRE header.

I would like to ask for the best way to implement this as a custom disscetor. Is it possible to extend the existing GRE dissector by adding a custom one or do I need to alter the existing GRE dissector source file?

I did not yet find a way to just extend an existing dissector. Did I miss something?

Bye, Jo

asked 26 Jul '13, 10:14

hhhannes's gravatar image

accept rate: 0%

Some dissectors, that are mainly used as transport protocols for other protocols, e.g. http, create a dissector table in order that sub-dissectors can add themselves to the table at run-time to allow a form of extension.

http.c is a good example as it creates two tables, a port table that allows sub-dissectors to register for http traffic over a particular tcp port and a media type table that allows sub-dissectors to register for a particular media type.

http.c also acquires the list of heuristic dissectors so that if no sub-dissector was found using the two tables described above a final attempt is made to locate a dissector to handle the data.

Unfortunately I can't see any info about dissector tables in the documentation, I'll raise a bugzilla enhancement for that, the only info I can see are the comments for the dissector_table functions in epan/packet.h.

Now in the particular case of gre, it creates a register table keyed on the gre 'type' field. Assuming your dissector uses a gre "type" value that is different to all existing types then you can add your sub-dissector to the gre sub-dissector table using code similar to the following in your dissector proto_reg_handoff_xxx routine:

dissector_add_uint("gre.proto", proto_type, proto_handle);

where proto_type is a guint32 that is the gre protocol type value indicating that it contains traffic for your sub-dissector and proto_handle is the dissector_handle_t returned from your sub-dissectors call to [new_]create_dissector_handle().

If you protocol re-uses an existing type value then you're stuffed and you get what you deserve for abusing the protocol and your only option is to modify the gre dissector.

permanent link

answered 28 Jul '13, 02:45

grahamb's gravatar image

grahamb ♦
accept rate: 22%

Thanks very much, this helped me a lot.

Now for this "new" protocol which has indeed its own protocol number, wireshark always reports "GRE (0xabcd - unknown)" in the GRE tree. Do you know if there is a way to overwrite this kind of information from the source code of my new dissector with the name of my new protocol?

(28 Aug '13, 02:34) hhhannes

Is the tree item you mention the encapsulated protocol, if so then I think you have to extend the gre_type_vals structure in the gre dissector.

There doesn't appear to be any mechanism to extend that structure when a sub-dissector adds itself to the gre table. What could be done is to modify the gre dissector to try a lookup in gre_type_vals and if the type value isn't found, then check in the sub-dissectors table.

You should file an entry in Bugzilla for that, maybe attaching a patch with the skeleton of a gre sub-dissector to ease testing.

(28 Aug '13, 03:13) grahamb ♦

I did not yet find a way to just extend an existing dissector. Did I miss something?

'Extending' a dissector is only possible by adding code to the existing dissector or by replacing the existing one with a new dissector for that protocol.

Reason: Wireshark (the packet analyzing engine) tries to identify a dissector for a frame by looking at several criteria (ports, protocols, etc.). As soon as Wireshark found a matching dissector it calls that dissector and hands over the (remaining) frame bytes to be dissected. The whole protocol processing takes place within the dissector, unless the dissector has either finished, ore found a problem (unknown data structure) or calls another dissector for further dissecting sub-protocols.

So, the only way to dissect a new protocol data structures (new TLV fields), would be to either extend the code of the current dissector or write a new dissector.

There is no 'Hook'-system to 'extend' an existing dissector by calling an 'external' routine, as soon as the original dissector detected an unknown data structure, although that might be a useful feature in some cases.

At least that's my understanding of the Wireshark code. I may be wrong though... ;-)


permanent link

answered 27 Jul '13, 00:44

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

If you have proprietarry extensions to an existing protocol you might be able to add the "hooks" you need to the existing dissector and have that code added to the existing dissector. If it can be done in a general enogh way. Then you can have your private dissector using those hooks. Some dissectors allready have such hooks(dissector tables). Some protocol have registration procedures for vendor specific additions in which case those should be used. See IANA as an example.

(28 Aug '13, 03:50) Anders ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 26 Jul '13, 10:14

question was seen: 3,563 times

last updated: 28 Aug '13, 03:50

p​o​w​e​r​e​d by O​S​Q​A