Hi, I have a shell script which uses tshark to monitor incoming video traffic, created by an ffmpeg process launched from the same script. I want to capture until another process ends - so ideally until there has been a gap of X seconds since the last packet was captured. I can't find a way to specify this using parameters, but have managed to almost solve it by capturing the tshark pid, then killing it when the process it is monitoring ends. This is not a problem on the face of it, since I capture the tshark PID at process start. However, when I do this the dumpcap process is often left running forever... Any ideas how I can kill both tshark and the dumpcap process it has created...? asked 14 Jun '17, 02:43  dbrb2 |
2 Answers:
Do you need tshark decoding the incoming packets? If not - meaning you're only interested in capturing the packets, not any packet details during capture - you could just run dumpcap instead of tshark from your script and kill it instead directly. answered 14 Jun '17, 02:47  Jasper ♦♦ |
While Jasper's answer is the better overall solution I'll try to answer the initial question. tshark catches both SIGINT and SIGTERM and (tries to) clean up its child process (dumpcap) after catching those signals--so You mention that it "often" doesn't work which is odd; I tried a few times here (with a fairly old version, no less) and it worked each time. There may be a problem lurking here but unless you're using a different signal (like SIGKILL) you were already killing tshark the "nice" way. UPDATE Actually it occurs to me that if you were using a signal other than SIGINT or SIGTERM then that could explain the behavior you were seeing: the SIGKILL would clearly kill tshark without allowing it to clean up dumpcap. Now IFF no more packets were received then dumpcap would hang around doing nothing. As soon as another packet is received, however, dumpcap will try to send a notification to tshark and should then get a SIGPIPE which would kill off dumpcap. (You mentioned that you were killing tshark after a test was completed which could mean "no more packets for a while.") answered 14 Jun '17, 06:42  JeffMorriss ♦ edited 14 Jun '17, 07:24 I agree with Jasper and Jeff too, but if for some reason dbrb2 really wants to use As opposed to only killing tshark via (14 Jun '17, 07:12) cmaynard ♦♦ |
Possibly - currently I run tshark to capture the traffic from a particular source (since there will be traffic from many sources on the interface) and save it to a pcap file:
$TSHARK -i $INTF -w $PCAP host $IP > /dev/null 2>&1&
At a later stage, I then decode and analyse this data: $TSHARK -r $PCAP -d udp.port==$PORT_RANGE,rtp -T fields -e rtp.seq > $FILE 2> /dev/null&
It is the first command that occasionally hangs. Am I right in thinking that dumpcap can do the filtering - it is the decoding of protocols that tshark brings - meaning I could use:
$DUMPCAP -i $INTF -w $PCAP -f "host $IP" > /dev/null 2>&1&
dumpcap does the BPF filtering, so if you're using capture filters (like it looks you are) it can do that. I always recommend running dumpcap directly instead of Wireshark/tshark because it's much leaner and less prone to crash due to out-of-memory situations.
That looks like it is going to work - so I am now using dumpcap to capture, using a capture filter to grab only those from a source IP I am interested in, and saving to a pcap file. Later, I use tshark to decode this traffic by reading in the pcap file.