On Fri, Jul 25, 2008 at 10:06:34AM -0400, Jeff Morriss wrote:
> 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
This looks like what I was expecting to see by default. If a file has to be
involved, it might be a good idea to make this the default behaviour as
opposed to filling up the disk and dying :)
Thanks for the trick in the meantime.
On Fri, Jul 25, 2008 at 12:00:15PM -0400, Fender, Brian wrote:
> Why not just use capture the raw data with tcpdump with -W and -C
> options to limit file size, then replay in tshark at whatever verbosity
> you desire?
I need forever real time capture/analysis. Anything that involves a file
that is parsed later (except maybe for a ring buffer), isn't the right
answer :)
On Fri, Jul 25, 2008 at 10:40:52AM -0700, Guy Harris wrote:
> > Tshark however seems to capture to /tmp/etherXXXXjRZvbB with dumpcap
>
> It shouldn't be doing that if tshark isn't run with the -w flag; it
> should, instead, tell dumpcap to write the capture to a pipe, and read
> from the pipe, so that it doesn't waste disk space on packets that
> will be read once to dissect them and never read again. See bug 2743,
> which I just filed.
Indeed, I really wish they would use pipes, at least as an option.
Thanks for the answers,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
