On Fri, 6 Sep 2002, Ronnie Sahlberg wrote:
> Hi list,
>
> There has not been any comments last week at all for the api i proposed and
> later checked in
> and that is used by tethereal and gtk2-ethereal.
>
> Well, is it just useless bloat or do you approve of the feature?
Looks good. Would it be possible to pass the the protocol tree to the
"packet" routine along with the tap data and packet info?
> I would really like to see a lot of new extension for statistics and other
> thing
> to ethereal.
>
> Examples of similar features that could be useful and would be simple to
> implement:
> * Sorted by NFS filehandles: number of reads/writes, aggregated number of
> bytes read/written
> * For NFS (and perhaps for specific files): Number of I/Os <=8kb and RTT,
> number of I/Os >8kb <=16kb and RTT, number of I/Os <64kb and RTT .
> * For NFS and a specific file: a graph where the y-axis represents the file
> offests from 0 to
> the end of the file and the x-axis the time from the begining of the
> capture. Mark each read/write
> as a horizontal bar in the graph from offset-to-offset+len at time x on the
> x-axis.
> This would display nicely just how the i/o/ to a specific file is done and
> file throughput up at the
> NFS layer.
> * ...
> (plus similar things for CIFS?)
>
> Ideas, are these things desired in ethereal or just bloat that could better
> be solved by
> running external perl programs over the capture file?
Two uses that come to mind immediately are
- Generalizing the capture progress window, so that you can pick and
choose what protocols are listed.
- Passing data on to an expert system for higher level analysis,
sort of like what NAI's Sniffer has. Passing an already-dissected
tree to the tap receiver would be helpful in this case.