Ubuntu
wireshark package

tshark uses up all the space in /tmp

Bug #210670 reported by Martin Pool
8
Affects Status Importance Assigned to Milestone
Wireshark
Unknown
High
wireshark (Debian)
Confirmed
Unknown
wireshark (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

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.

Revision history for this message
In , Guy Harris (guyharris) wrote :

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.

Revision history for this message
In , Rtarty (rtarty) wrote :

Created attachment 2290
Script to reorder TCP streams.

Last version of Scapy requiried.

Revision history for this message
In , Jeff-morriss-ws (jeff-morriss-ws) wrote :

Comment on attachment 2290
Script to reorder TCP streams.

This attachment was meant for bug 2722.

Revision history for this message
Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.04 or 8.10?

Changed in wireshark:
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Martin Pool (mbp) wrote :

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

Changed in wireshark:
status: Incomplete → Confirmed
Revision history for this message
In , Jeff-morriss-ws (jeff-morriss-ws) wrote :

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.)

Revision history for this message
Gerald Combs (gerald.combs) wrote :

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

Revision history for this message
In , Balint Reczey (rbalint) wrote :

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.

Revision history for this message
Ken Sharp (kennybobs) wrote :

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

Revision history for this message
Ken Sharp (kennybobs) wrote :

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

Changed in wireshark (Ubuntu):
status: Confirmed → Invalid
Martin Pool (mbp)
Changed in wireshark (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Martin Pool (mbp) wrote :

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.

Revision history for this message
In , Guy Harris (guyharris) wrote :

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

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

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

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 210670] Re: tshark uses up all the space in /tmp

please forward it

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

Fowarded, please run apport-collect 210670

Revision history for this message
Balint Reczey (rbalint) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in wireshark:
importance: Unknown → High
status: Unknown → Invalid
Bug Watch Updater (bug-watch-updater)
Changed in wireshark (Debian):
status: Unknown → Confirmed
Logan Rosen (logan)
Changed in wireshark:
importance: High → Unknown
status: Invalid → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in wireshark:
importance: Unknown → High
status: Unknown → Confirmed
Revision history for this message
In , Hoangsonvnu (hoangsonvnu) wrote :

> 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?

Revision history for this message
In , Guy Harris (guyharris) wrote :

(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.

Revision history for this message
In , Rossbjacobs (rossbjacobs) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in wireshark:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.