tshark uses up all the space in /tmp

[Martin Pool]

Binary package hint: wireshark

I ran "sudo tshark -p -i eth0 -R http.request" which prints requests to stdout.

This creates an enormous dump file in /tmp, which eventually used up all the space on that partition. It didn't give an error, it just stopped logging once it was full.

It would be nice if it either used a pipe, or rolled over the file every so often. The command makes no use of packets captured a long time ago.

[Guy Harris (guyharris)]

Build Information:
TShark 1.0.2 (SVN Rev 25698)

Copyright 1998-2008 Gerald Combs <email address hidden> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GLib 2.16.3, with libpcap 0.9.5, with libz 1.2.3, without POSIX
capabilities, without libpcre, without SMI, without ADNS, without Lua, without
GnuTLS, without Gcrypt, with MIT Kerberos.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.

Running on Darwin 9.4.0 (MacOS 10.5.4), with libpcap version 0.9.5.

Built using gcc 4.0.1 (Apple Inc. build 5465).

--
TShark, when run without -w, isn't told to permanently save the captured packets to a file; it's only supposed to dissect and print the packets.

Currently, it does that by running dumpcap without "-w", so that it writes to a temporary file, and then reads the temporary file.

This means that if you leave TShark running for a long period of time, and it captures a lot of packets, a large capture file is written, which can fill up the disk;

In addition, it appears that, in some cases, the capture file isn't deleted.

TShark should run dumpcap in a mode where it writes the captured packets to a pipe, fflushing the output stream at the end of a packet batch, and reads captured packets from the pipe.

[Rtarty (rtarty)]

Created attachment 2290
Script to reorder TCP streams.

Last version of Scapy requiried.

[Jeff-morriss-ws (jeff-morriss-ws)]

Comment on attachment 2290
Script to reorder TCP streams.

This attachment was meant for bug 2722.

[Daniel T Chen (crimsun)]

Is this symptom still reproducible in 8.04 or 8.10?

[Martin Pool (mbp)]

Yes, it's still reproducible. Just run tshark then lsof and you'll see a regular tmpfile still in use.

[Jeff-morriss-ws (jeff-morriss-ws)]

Bug 1650 (error when using ring buffer mode when the buffer files are deleted before *shark gets to them) could also benefit from using a pipe to pass packets from dumpcap to *shark. (Doing that would also allow read filters to work while capturing again.)

[Gerald Combs (gerald.combs)]

TShark inherits that behavior from Wireshark (which _does_ let you go back in time). It probably shouldn't do that, but you can work around the problem using the ring buffer (-b) option: http://www.wireshark.org/docs/man-pages/tshark.html

[Balint Reczey (rbalint)]

The problem of not removing temporary capture file is reported to Debian BTS, too:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518904
I've set the bug in Debian BTS to track this bug.

[Ken Sharp (kennybobs)]

How is this a bug? The application is working as designed. Can this be closed?

[Ken Sharp (kennybobs)]

No answer in over a year, says it all. Application working as designed.

[Martin Pool (mbp)]

Ken, please don't close bugs when the bug still exists and the upstream maintainer has acknowledged "it probably shouldn't do that."

The reason it's a bug is pretty clear from the original report and the later comments: you run 'tshark' in a window to monitor traffic on the network. Some time later, tshark crashes and other parts of the system have trouble, because (on a default Ubuntu install) the root partition is now entirely full. There is no benefit to this behaviour and afaics no reason it needs to be implemented this way.

[Guy Harris (guyharris)]

*** Bug 6604 has been marked as a duplicate of this bug. ***

[Gianfranco Costamagna (costamagnagianfranco)]

@Martin I agree but IMHO this bug should be reported upstream to wireshark developers, not downstream

[Martin Pool (mbp)]

please forward it

[Gianfranco Costamagna (costamagnagianfranco)]

Fowarded, please run apport-collect 210670

[Balint Reczey (rbalint)]

Martin: It is not a bug.
If you don't want to fill your partition, please check the -b option as Gerald already suggested.

[Hoangsonvnu (hoangsonvnu)]

> TShark should run dumpcap in a mode where it writes the captured packets to a
> pipe, fflushing the output stream at the end of a packet batch, and reads
> captured packets from the pipe

@Jeff Morriss: Has this suggestion been done in tshark of the branch trunk-1.10? If we do this, does it mean we don't need a temp .pcap file stored in the disk and the data could be transferred directly from dumpcap to tshark via a pipe?

[Guy Harris (guyharris)]

(In reply to comment #6)
> > TShark should run dumpcap in a mode where it writes the captured packets to a
> > pipe, fflushing the output stream at the end of a packet batch, and reads
> > captured packets from the pipe
>
> @Jeff Morriss: Has this suggestion been done in tshark of the branch
> trunk-1.10?

As one might infer from the fact that this bug is in the CONFIRMED state rather than the RESOLVED/FIXED state, this has not been done anywhere in the SVN repository for Wireshark.

[Rossbjacobs (rossbjacobs)]

*** Bug 15298 has been marked as a duplicate of this bug. ***