From other Q&A's I've gathered that tshark may intrinsically grow without limit, and in auditing a home WLAN using low power devices (500-1000 MB RAM), I've found it runs out of memory in in 6-8 hours. The total volume of packets does not seem to be a predictor, although the volume within a short time frame (0.5 GB/hour +) may be. I'm only looking for specific information that it seems to me should not require this accumulation of memory, and hoping there's a smarter way to get it that can prevent this: Auditing a WLAN introduces a complication: I cannot arbitrarily restart tshark, because a constraint of monitor mode is that it must witness each device connecting to the network in order to track that device's packets. If I restart tshark, I must also restart the WLAN to force all devices to reconnect. There are only a handful of devices involved. Currently the filter I am using is -Y "ip && !ip.src == 192.168.0.0/24" Is there a way to do this which would extend tshark's potential lifespan? asked 24 Apr '15, 08:36  mk27 edited 24 Apr '15, 08:42 |
2 Answers:
This is a limitation of tshark (and Wireshark) as they are packet analysers not network monitors and retain state information such as conversations and eventually will run out of memory as you have found. The rate of memory use is more down to the relationship between the packets rather than packet size. I think you'll have to look for another tool to meet your requirements, which seem to involve WLAN decryption along with tcp port info and possibly other protocols in the frame. answered 24 Apr '15, 08:56  grahamb ♦ |
You could give a try to tshark from 1.99.X branch combined with the -b flag. See this blog post for details. answered 24 Apr '15, 11:34  Pascal Quantin The problem is not the output. It is the memory footprint of the tshark process; it continuously grows until the system runs out of RAM, then the OS kernel kills it. (25 Apr '15, 05:43) mk27 With the flag I indicated, the memory will be released each time you start a new buffer, thus solving the memory growth. (25 Apr '15, 06:19) Pascal Quantin |
I'd forgotten about Evan's changes. Does WLAN decryption still work after a buffer changeover?