This is our old Q&A Site. Please post any new questions and answers at

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

accept rate: 0%

permanent link

answered 08 Dec '14, 05:04

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 07 Dec '14, 08:11

question was seen: 2,663 times

last updated: 13 Dec '14, 10:12

p​o​w​e​r​e​d by O​S​Q​A