Ethereal-dev: [Ethereal-dev] Simple Extension API, patch for tethereal and rpcstat example
Hi list
Attached is a patch to current CVS for a simple API to create extensions
to [t]ethereal.
Currently the patch is really only useable for tehtereal since ethereal
would really
full and tested GLIB2 support (it would really need to have a low priority
thread that updates
/ tells all extensions to redraw in the background) It seems we are quite
close to that stage in
the glib2/gtk2 port so...
The patch consists of three parts:
1, the actual tap subsystem with tap points created at the frame and the
rpc layer.
Different tap points can provide different protocol specific data structures
as parameters,
such as the rpc_call structure in rpc.
2, an example user of said api : rpcstat.
RPCSTAT will tap the rpc tap and store information for all calls on how long
each call took to execute. It will only consider rpc calls where both teh
call and the reply has been seen.
rpcstat supports an arbitrary number of concurrent instances.
rpcstat should be able to do these stats for all rpc protocols and versions
that ethereal has dissectors for.
When told to redraw, rpcstat will print a simple table for all procedures in
the program/version
it monitored displaying TotalNumberOfCalls, MinRTT, MaxRTT, AvgRTT.
3, changes to tethereal to add a new cmdline parameter -Z
rpc,<program>,<version> which invokes an instance of rpcstat. There is no
limit on how many -Z parameters one can use concurrently.
When tehtereal exists, it will tell all tap users to draw/redraw its
statistics.
tap.cmd shows the commandline i used with the nfsv3 example cpture from the
website.
tap.out shows the normal tethereal output followed by the statistics for nfs
v2 and v3. The RTT values are as they are since the timestamps in teh
capture is not too great.
tap.diff is the patch.
rpcstat's primary function is to demonstrate the API and its simplicity but
is quite useful.
nfs people may find this feature very useful.
Please comment. I think it is reasonably clean to go into cvs but want
comments first.
There is one perfromance issue in the patch in tap.c:
+ for(tp=tap_packet_list_queue;tp;tp=tp->next){
+ for(tl=tap_listener_queue;tl;tl=tl->next){
+ if(tp->tap_id==tl->tap_id){
+ int passed=TRUE;
+ if(tl->code){
+ edt=epan_dissect_new(TRUE, FALSE);
+ epan_dissect_prime_dfilter(edt, tl->code);
+ epan_dissect_run(edt,
+ l_pseudo_header,
+ l_buf,
+ l_fdata,
+ NULL);
+ passed=dfilter_apply_edt(tl->code, edt);
+ epan_dissect_free(edt);
+ }
+ if(passed && tl->packet){
+ tl->packet(tl->tapdata, tp->pinfo, tp->tap_specific_data);
+ }
This loop loops over all packets that have been queued in the dissectors,
packet-frame.c packet-rpc.c and also over all applications listening to
those taps (application: tap-rpcstat.c instances)
For each potential application, apply the filter to see if the application
really wants us to callback.
Here we do a full epan-thing with dissect several times. once for each
instance.
Maybe it is possible to optimize this to only do the decode here once, but
the filtering multiple times? That would enhance performance.
I dont know much of epan and dont know if this would be possible or not.
Perhaps someone with a solid understanding of epan could look into this? it
seems an awful
waste of cpu to do a full decode even though we just want to apply a filter.
I would later want to have something similar for ethereal as well, but
controlled by a GUI.
best regards
ronnie sahlberg
(this is the first time i am aware of sending in a patch that adds really
useful features to tethereal and not ethereal)
[Filename: tap.cmd, Content-Type: application/octet-stream]
The attachment file in the message has been removed by eManager.
Attachment:
tap.diff
Description: Binary data
Attachment:
tap.out
Description: Binary data
