Two things perhaps someone could look at
tethereal has now some tethereal specific extensions :
tap-rpcstat.[ch] tap-rpcprograms.[ch] and maybe a lot more in the future.
I think we should consider tethereal a proper port and thus give it its own
subdirectory ./tethereal/ in the same way as gtk and gtk2 ports have their
own subdirectories. The gui ethereal ports have no need to link with or
know about the tap-rpc*.[ch] files.
tethereal has a Verbose flag.
Perhaps tethereal should also have a Quiet flag which does not print any
packet-lines but only output from tap extensions and nothing else.
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.
> --- Ronnie Sahlberg wrote:
> > Of course, it is actually even more useful for
> > tethereal users since it can
> > be scripted.
> >
> >
> > tethereal -n -r foo.cap.gz -z rpc,rtt,100003,3
> > Creates a text table after all other output similar
> > to the png from
> > ethereal.
> > What the magic numbers 100003 and 3 refer to i leave
> > as an excersise for the
> > reader.
> >
> > or
> >
> > tethereal -n -r foo.cap.gz -z
> > rpc,rtt,100003,3,nfs.fh.hash==0x12345678
> > (for stats for a specific file, when filtering for
> > nfs.fh.hash, dont
> > forget to enable the nfs.fhandle_find_... option)
> >
> >
> > For tethereal powerusers:
> > This uses magic to create one RPC RTT stat for each
> > and every NFS file that
> > exists
> > in the capture:
> >
> > tethereal -V -n -r foo.cap.gz | grep hash | sed -e
> > "s/.*hash: //" | sort |
> > uniq | while read HASH ;do
> > tethereal -n -r foo.cap.gz -o
> > "nfs.fhandle_find_bith_reqrep:TRUE" -z
> > "rpc,rtt,100003,3,nfs.fh.hash==$HASH" | tail -27
> > done
> >
> >
> > This first scans the capture to find all filehandle
> > hashses,
> > then for each hash it calls tethereal again to
> > generate rtt stats for that
> > particular file.
> >
> > tethereal is called once for each hash. performance
> > can be improved if it is
> > rewritten to only call tethereal once here but with
> > multiple -z commands.
> > one -z for each hash.
> >
> >
> > This is quite powerful and something i dont think
> > any other tool can do.
> >
> >
> >
> > If you are getting ideas about DCE-RPC stats like
> > this. Probably very easy
> > to implement but first DCERPC must be enhanced to
> > calculate and display the
> > RTT as ONC-RPC does.
> > This is trivial and probably consists of like 10-15
> > lines basically copied
> > from packet-rpc.c
> >
> > We could start generating stats for any interesting
> > protocol this way. I
> > started with ONCRPC since it was easiest and it
> > would automagically cover
> > some 20-25 interesting higher protocols.
> > DCERPC would definitely be good to have.
> > Then specific ones such as DNS, SMB,ARP,ICMP-echo,
> > ...
> >
