To Infinity and Beyond! Capturing Forever with Tshark
Categories:
Announcement
Over the last couple of years that I’ve been involved with Wireshark, one issue has reared its head a significant number of times in a surprisingly varied number of ways. These range from “Capturing with tshark uses more and more memory!” to “I set tshark to capture in the background, and it keeps crashing!” to “How do I set up tshark to capture forever?”
Historically we’ve had no good answer to these complaints – Wireshark and tshark both only do what is called stateful dissection. This means that they store what they’ve seen in memory and use that information to provide additional details about future packets, for example by matching requests with responses. While this provides substantial benefits — reassembly of protocols over TCP being probably the most obvious — it means that as the amount of traffic increases, so does the amount of memory needed to store all of that state. It also means that there’s no way for tshark to run forever unless you’ve got infinite memory (what’s your secret!?) or no traffic at all.
All of that has just changed.
Detecting Heartbleed Traffic
The big news in the tech industry this week is The Heartbleed Bug, a vulnerability that affects a large portion of secure web sites on the Internet. I updated the Wireshark and WinPcap web sites on Monday (along with reissuing and revoking certificates) shortly after OS patches were released.
Our web sites are protected going forward, but what about the past? We have a Shark appliance in our environment but that leads to a challenge. We had about 350 GB of HTTPS on our network on Monday alone. This is just slightly too large to load into Wireshark.
Fortunately one of my coworkers (P.J. Malloy) came up with a BPF filter that matches Heartbleed traffic:
http://www.riverbed.com/blogs/Retroactively-detecting-a-prior-Heartbleed-exploitation-from-stored-packets-using-a-BPF-expression.html
Applying this filter directly on the Shark appliance gave me a much smaller number of packets which I could easily analyze in Wireshark. So far I haven’t found anything suspicious.
We’re switching to Qt.
Categories:
Announcement
Today I released the next development version of Wireshark, 1.11.0. This marks a major change in the direction of the project. We’re switching our user interface library from GTK+ to Qt. Both libraries make it easy for developers write applications that will run on different platforms without having to rewrite a lot of code. GTK+ has had a huge impact on the way Wireshark looks and feels and on its popularity but it doesn’t cover our supported platforms as effectively as it should and the situation is getting worse as time goes on.
Making such a large change wasn’t an easy decision. It means rewriting thousands of lines of code and requires a lot of careful design. We might be the largest standalone application to make this transition (feel free to correct me below). However, I think it’s well worth it and that it’s important to the long-term direction of the project. Ultimately it came down to one thing:
Wireshark’s job is to show you what’s happening on your network. If it can’t run on your system then it’s not doing that job.
Recent Posts
- Those Aren't Packets: How Stratoshark Brings the Power of Wireshark to the Cloud
- What’s New In Wireshark 4.4?
- From Network Packets to Log Data: How Logray built upon Falco’s foundation
- The evolution of system introspection from BPF to Wireshark to Falco
- Wireshark Is 25: The email that started it all and the lessons learned along the way