This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Why does tshark on Raspian lock up sometimes in monitor mode ?

0

I have multiple identical Raspberry Pi B+ side by side. All use a Ralink RT5370 wireless usb dongle that is running in monitor mode. The problem is, tshark in only some of the machines dies at the same instant, presumably when the machines process the same packet. The capture file of the WiFi stream being fed to tshark keeps growing, so the input does not freeze. WiFi traffic is low, the total cpu usage is only a few percent, and there's plenty of memory available. I'm running the latest everything (Dec 2014).

How do I fix this ?

Also, is monitor mode able to receive all WiFi channels simultaneously ?

Thank you in advance.

asked 07 Dec '14, 08:11

NewtownGuy's gravatar image

NewtownGuy
9224
accept rate: 0%


One Answer:

0

answered 08 Dec '14, 05:04

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thank you for your reply. However, in my case, it's only my script's processing of packets captured by tshark (apparently using dumpcap) and piped to it that freezes. The machine continues to run fine otherwise. Packet capture from the wlan0 interface continues to run as evidenced by the continually growing size of the capture file. I have also seen this on the older Model B. All of my tests use WiFi dongles with the Ralink RT5370 chipset since I need to use monitor mode. I will see if I can get another make of dongle that supports monitormode, but the fact that the packet capture continues to run makes me think the driver is OK. It acts like the pipe breaks, or tshark freezes, but I don't know how to confirm this. Any suggestions ?

(08 Dec '14, 05:56) NewtownGuy

Any suggestions ?

well, how does your script look like and how are you calling what?

(08 Dec '14, 06:36) Kurt Knochner ♦

dumpcap is the process used by tshark (and Wireshark) to do the actual capture, it does sound as though something in tshark is hitting an issue. I suspect that you'll have to debug this yourself on the target machines.

Note that neither tshark or Wireshark can be used for continuous capturing as they retain state as the traffic is dissected and will eventually run out of memory, have you checked for this?

(08 Dec '14, 06:37) grahamb ♦

The capture file is stored in /tmp, the default. I delete it periodically and restart the process so I don't fill up the disk with capture data.

I now have TEN different but identical machines running side by side. I have seen as many as FIVE of them all fault at the same time. What I mean by fault is, tshark stops pipeing the output file to my app. The capture process continues, so the network interface is still running. I can't find any error messages or warnings, the pipe just stops. I have a script that detects the fault and restarts it, creating a new capture file and sending me an alert so I know to check it. My processing script is the same on all ten machines, and all machines are monitoring the same WiFi channel, so my script is ok.

Why does tshark stop pipeing its output to my script ??????

I doubt it matters, but I'm trying to configure tshark to configure dumpcap to write the raw capture data to a circular buffer (10 files, each 15 MB) in /var/tmp, which is a RAM disk, but I can't make it work. I made a separate post on this one question. tshark does not like the specification of capture files for dumpcap, it confuses them with writing its output.

Any suggestions on either the pipe problem or the buffer problem ?

(13 Dec '14, 08:40) NewtownGuy