Ethereal-dev: Re: [Ethereal-dev] tap for tethereal

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx>
Date: Sun, 29 Sep 2002 13:00:08 +1000
From: "Jaime Fournier"
Sent: Sunday, September 29, 2002 10:40 AM
Subject: Re: [Ethereal-dev] Re: [Ethereal-cvs] cvs commit: ethereal NEWS
ChangeLog


> dce/rpc was exactly what I was thinking.
> Current i use tethereal to capture live, and archive
> just the info lines.  Would it be possible to run it
> on a live capture?
> If not I can always stick with limited capture files.
> Just an idea.

It is certainly possible.
The current implementation just calls
draw_tap_listeners(TRUE) once, when tehtereal has reached end-of-file and
exits.
This causes the tap system to update all registered tap extensions when
called, unconditionally at that point.

To get tethereal to output this data at other times or regularly one would
only need to device a way to regularly make tethereal call
draw_tap_listeners(TRUE).

Perhaps when it receives SIGUSR1?  But that would not work on w32?
since they dont have signals?


The stats are printed on stdout so it will be intermixed with the other
output as well
from tethereal but thats nothing a small script/sed magic can not solve.

Maybe changing tap-rpcstat.c output to print to stderr but that might be
ugly, but it would be easier to differentiate between normal tethereal
output and  these tables.


To do this for regular intervals for dcerpc needs careful planning.
It would not work just to run a loop like capturing tethereal for 10seconds,
printing the table and restarting tethereal since next time you run
tethereal would not remember the bind calls and thus would not know how to
dissect the packets.

DCERPC would need something that at regular intervals called
draw_tap_listeners(TRUE).
Does tethereal have anything like the ringbuffers thingie?

options as i see it, may be much better ones if you give it some thought:
Perhaps it could work if you required ringbuffers for tethereal and whenever
tethereal switched to a new ringbuffer it would also call
draw_tap_listeners(TRUE)?
This would at "regular" intervals draw a new aggregate struct.

Optionally, just use the signal handler for SIGUSR1 but then it wouldnt work
for the w32 crowd.



Also, important thing for you to look at if you plan to extend tethereal in
this way:
The stuff above would not reset the stats after each time you printed the
previous intervals stats.
Reseting the stats can easily be done by a call to reset_tap_listeners().
If you want to do this as well I think you must look at tap-rpcstat.c to see
if it is implemented properly. I did not envision that tethereal would do
anything else than print it once, when tethereal exits so the reset callback
there may be incomplete/wrong.

?   SIGUSR1 to print stats
?   SIGUSR2 to reset stats