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, > > ... > >
