[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

This should allow you to capture to a ring buffer while also 
decoding/displaying the messages:

tshark -b filesize:10000 -b files:5 -w /tmp/foo -nVS

(The "-S" is important otherwise tshark will assume that because you're 
writing to a file you don't really want the "-V".)

You do need to be careful that your tshark is able to decode (and write 
to its stdout--which means your script's speed matters too) faster than 
the data is coming out, see:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1650

Marc MERLIN wrote:
> On Thu, Jul 24, 2008 at 11:05:59PM +0400, Abhik Sarkar wrote:
> > On Thu, Jul 24, 2008 at 9:10 PM, Marc MERLIN <marc_ws@xxxxxxxxxxx> wrote:
> > > Can I either:
> > > 1) skip dumpcap and not have an ever growing file?
> > From what I understand, dumpcap was introduced to meet this objective:
> > http://wiki.wireshark.org/Development/PrivilegeSeparation. tshark
> > spawns dumpcap, and capture is not possible without this.
>
> Right. It's a good idea for most, but quite undesirable for me. It'd be nice
> if that could be turned off since it prevents running tshark in live capture
> mode for a long time.
>
> > > 2) tell tshark to quit when the dumpcap file is 10G and I'll restart it in
> > >   a loop after /bin/rm /tmp/etherXXX*
> > You should not have to clean-up these files manually if the processes
> > were terminated cleanly. There has been some discussion on this
> > recently, as you might have seen:
> > http://www.wireshark.org/lists/wireshark-users/200807/msg00127.html.
> > If you are also facing this issue, it probably needs to be looked into
> > more carefully.
>
> Honestly, the loss of work from having a 2 day process capture die is high
> for me and since I've seen tshark die on out of disk space and the ether
> file left around in /tmp, I'm just going to delete them all on restart.
>
> > Here are a few suggestions:
> > - you could use the -c option and restart in a loop, but you risk
> > losing packets between the restarts
>
> Looks like the winning proposition for me right now.
> I'll just set -c 1000000
>
> > - I don't know for sure if it is possible, but you could try the
> > reverse of what is mentioned in
> > http://wiki.wireshark.org/CaptureSetup/Pipes
>
> I doubt that will work, if have no control over the tempfile dumpcap/tshark
> create and share, and if I have tshark output to a file, it turns off
> protocol decoding.
>
> > - Haven't ever tried this, but maybe it is possible to use a ring
> > buffer with a named pipe as an output file.
> > (I am not quite sure if the last two options would prevent the dumpcap
> > file from growing though...)
>
> Ouch :)
>
> I think I'll use this for now:
> (while :
> do      
>         /bin/rm /tmp/etherXXXX*
>         # tshark uses a tempfile to dump and analyse from, which means we
>         # can't have it grow forever, so we restart tshark every 1 million
>         # packets and delete the old file left behind if it died with an error.
>         tshark -c 1000000 -n -V -l -i eth1 port nfs and host 172.28.80.41
>         echo "tshark finished with $?, restarting" >&2
> done) | ~/analyse_nfs > out$$ 2>err$$
>
> Thanks,
> Marc