Hey, 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 |
2 Answers:
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: 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. answered 28 Jul '13, 02:45  grahamb ♦ |
'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... ;-) Regards answered 27 Jul '13, 00:44  Kurt Knochner ♦ 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 ♦ |
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?
Is the tree item you mention the encapsulated protocol, if so then I think you have to extend the
gre_type_valsstructure 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_valsand 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.