Wireshark · Ethereal-dev: [ethereal-dev] Modularity for packet decoders

["Johan Feyaerts" <johan_feyaerts@xxxxxxxxxxx>]

There has been a lot of discussion about adding modules to ethereal by means
of scripting etc...
I'd like to add some stuff to the discussion:
A scripting language is not strictly necessary for ethereal and has the 
following disadvantages:
-slows down the tool
-you need additional files to start up, this is less comfortable than 1 
executable.
-takes a lot of effort to make and works only for simple protocols

In the ideal case you have both a scripting language and a modular decoder 
concept.
They are not mutually exclusive, but complementary.

You can realize modularity also in a different way, by linking additional 
modules to an archive and generating a new executable. An advantage of this 
modular approach would be that you can easily write a generator for making 
at least a template packet-xxx.c packet-xxx.h and packet-xxx-interface.h 
file. This could significantly decrease the time to add a new protocol.

In order to do this the different protocol modules should be separated from 
eachother and use function pointers to call eachother instead of direct 
function calls. At startup each module should register with one or more 
parent protocol modules. In this way each protocol module maintains a table 
of function pointers to its children dissectors. (you have to get rid of the 
switch/case constructions in the dissectors, using hash tables would 
increase the speed even more) The only thing a module needs to know about 
his parent is the registration interface in the 
packet-protocolname-interface.h file. This should be the only thing a child 
needs to know to register with the parent.

One of the things that would increase functionality would also be a general 
settings menu in the mainwindow on which the  protocol could register with a 
menu item and a callback function. In this way each module can can be called 
when its menuitem is selected and can popup its own settings window. e.g. A 
window where a dictionary or shared secrets are configured for the RADIUS 
protocol.  You could also think about a registration of a track-menu that is 
called when the packet is selected and you click on the right mouse button.

Furthermore a protocol module could register with a general filtering engine 
to which it tells on which fields and which value types (ip address, 
character string, numeric field) filtering can be done.

One thing that would increase modularity even more is that 'non-leaf'
protocol modules would pass decoded information in an array to a higher 
level module. In this way the most important decoded info is also available 
for the higher layers. This could be done by passing an array of {char 
*module name, void *info} to the higher layer dissectors. If a module wants 
to pass info to the higher layer it should add its a pair to the array with 
its module name and a pointer to a structure with the decoded data. The 
structure of the data that the module exports could be exported to the 
others in the packet-xxx-interface.h file.

I've made a small prototype that shows how you could make a binary
distribution to which additional modules can be added by means of a linking 
step.
First do a makearch, this makes the binary  distribution ethereal.a
Then you can do a make1, make2, make3 to see how linkable packet-xxx.o
modules can be added to the main software. There is no need to recompile the 
main module to add a packet decoder module.
I've used the g++ compiler because C++ allows  static
variables to be initialized with function calls. That's the trick to make a 
module register itself. If you don't want to use C++ you could achieve the 
same thing by having a file that contains an array of pointers to 
registration  functions of the modules that are added by the user. In this 
array somebody would have to add pointers to his specific modules. The 
main() function would then have to call these functions to make the extra 
modules register themself with their parents. see attachment tar file

Some future decoders decoding may be be very time consuming e.g decrypting 
encrypted stuff.
In order to increase speed it would be good to have a parameter in the
dissect routine which says if it's called for a full decode (for the tree 
view, filter ? or packet print) or a less complete decode for the packet 
list view (without having to parse the whole packet in full detail).

Kind Regards,
Johan Feyaerts,
Johan.Feyaerts@xxxxxxxxxxxxxxx


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Attachment: linkmodule.tar
Description: Unix tar archive