Wireshark-users: Re: [Wireshark-users] tshark crash with capture ring buffer (-b) and decoding pa

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Fri, 11 Jan 2013 10:09:23 -0500
Will Cladek wrote:
The following happens on both tshark 1.0.15 installed from Red Hat package on CentOS 5 and 1.2.15 from package on CentOS 6.

I am attempting to run tshark on a high-utilization link in a manner that will print out, using display filters, the user agents of all HTTP requests. The first problem is that by default, tshark writes all raw data to temporary capture files in /tmp, so if you leave it running endlessly, it fills up all of the disk space on the system. To resolve this, I use the -b option to write to a few files of a set size which are overwritten.

With just the -b option, I can seemingly run tshark endlessly. For instance, I ran the following simple capture overnight:

#> tshark -b filesize:100000 -b files:5 -w test.pcap -i eth4

And came back the next morning with over a billion packets having been processed, but no complaints.

My problem comes when I throw in the -S option to print out the decoded packets as well for my aforementioned purpose. I run the following command:

#> tshark -S -b filesize:100000 -b files:5 -w test.pcap -i eth4 > /dev/null

And every time, within a minute, tshark crashes with the message:

tshark: The file "test_00005_20130111092347.pcap" doesn't exist.

(The name of the .pcap file will obviously vary.)

This is follwed by either "Segmentation fault" or something like "*** glibc detected *** tshark: double free or corruption (fasttop): 0x00002ba03da05de0 ***" followed by a printed out Backtrace.

It appears that there is some kind of condition where tshark tries to delete a ring buffer file that's already been deleted, and this only occurs when the -S flag is used.

This is an old problem:

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

Basically tshark isn't keeping up with the rate of traffic that dumpcap (the capture utility) is writing. dumpcap has gotten N (in your case 5) files ahead of tshark and removed a file before tshark even got to it.

In other words: dumpcap is writing packets much faster than tshark is able to read and decode them and then print out the results of that decode.

One suggestion would be to avoid doing a full decode and print ("-S") but rather limit the decode output significantly ("tshark -T fields -ehttp.referer"). That might help. You could also mess with process priorities and the like but I doubt that would buy you much.