Ethereal-users: Re: [Ethereal-users] Three big problems

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

From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
Date: Sat, 2 Nov 2002 08:46:44 +1100
Sent: Saturday, November 02, 2002 4:45 AM
Subject: RE: [Ethereal-users] Three big problems


> Justin,
>
> > 1)  I have a 2GB capture file that I need to split.  I don't
> > particularly care if it's split into chunks of NN packets or
> > files of some size, but I certainly can't analyze the file as
> > it is.  Second best would be a suggestion for an algorithm I
> > could implement in Perl that would allow me to use editcap to
> > split the file without knowing how many packets are in the
> > file.  (e.g.  "while <some test>, editcap -r infile
> > next.outfile <next chunk>").

Try editcap, it might do what you want.

> > 3)  I need to be able to use at least 1000 files in the ring
> > buffer (although about 60,000 would be much better).  This
> > one is by far the most important, since if I can get past the
> > 10 file limitation I can worry about item 1) above and make
> > do, but with only 10 files in the ring buffer I'm screwed.

That many files is not supported by ethereal, neither do I think it will be.

> > The deal is that I need to run a perpetual packet capture on
> > a 75+ Mb link and I need to buffer to hold at least 3 days
> > worth of data.  I have the disk space and the server hardware
> > to do this, but I'm limited by Ethereal.

I do these things from time to time in the lab when it might take several
days of auto testing
to recreate a situation.
When I need to do this I usually implement it something like
#!/bin/sh
while true;do
    filename=`date +"%Y%m%d-%H%M%S"`
    tethereal -s 1500 -i eth0 -w $filename -c 200000
    gzip $filename &
done

Or use snoop or tcpdump instead of tethereal.


> Are you just looking for a particular event? Ethereal can't do this (yet),
> but you can get NG Sniffer to start storing a capture to disk when it sees
a
> particular trigger frame.

Yes, but if the trigger frame is detected by using a filter, then you are
almost stuffed anyway since
ALL filtering in it works like :
"check-byte-at-offset-x-and-compare-it-to-y"
Thus, try to create a filter to find say a specific nfs filehandle or
anything which offset may move inside the frame.   Good luck.
Or your trigger didnt fire since when the situation occured on the network,
by random fluke, there was an extra ooption in the IP header shifting the
entire payload a few bytes inside the frame and thus the trigger/filter
didnt match.


What makes ethereal filtering/triggering slow is the actual feature that
makes ethereal the only tool capable of doing proper filtering.
You just cant do proper filtering without doing a FULL decode of each and
every packet.