Let me tell you about Wireshark 2.0

We’re getting ready to release Wireshark 2.0, which includes a major user interface update. As a comparison, here’s a picture of Wireshark 1.12.8, which is the current stable release:
Main window 1.12.8

Here’s a picture of Wireshark 2.0.0rc2, which is the current development release:
Main window 2.0.0rc2

See? Totally different.

Actually, quite a few things have changed. The user interface has been completely rewritten using a different interface library (Qt). It has been streamlined so that you can work faster and it should have a better look and feel on every platform. The screenshots above are similar because we’ve also tried to ensure that the new UI is familiar to current users. The features you’re used to are still there and in the same place (or at least nearby). They should work much more smoothly, however.

I can’t hope to cover all of the changes in Wireshark 2.0 in one blog post, but here are a few highlights:

Capture options. Capture options have been simplified and consolidated. In 1.12 they are spread out in many places across several windows. In 2.0 they are in two places: the Capture Options dialog (Capture→Options or the “gear” icon in the toolbar) and the Manage Interfaces dialog, which you can open by pressing “Manage Interfaces” in the Capture Options dialog.

Streamlined preferences. Preferences windows usually aren’t something to get excited about and this is no exception, but it’s important to note that in the process of removing clutter some preferences have been removed from the main window. They’re still available in the “Advanced” preference section which lists every available preference item.

Translations. Thanks to the hard work of many contributors the new interface supports multiple languages. You can now select between Chinese, English, French, German, Italian, Japanese, and Polish in the “Appearance” preferences section. Many more translations are underway. You can see the status the translation efforts and help out with the effort at https://www.transifex.com/wireshark/wireshark/.

Related packets. As you scroll through the packet list you might notice little symbols pop up along its left edge. For example, you might see left and right arrows for DNS requests and Replies, or a check mark to denote an ACKed TCP packet. These are related packets. This exposes some plumbing we’ve had in place for a long time, but it’s now shown in the main window instead of buried deep in the packet detail tree.

Intelligent scrollbar. As you scroll through the packet list you might notice that the scroll bar itself looks odd. It now features a map of nearby packets, similar to the “minimap” available in many modern text editors. The number of packets shown in the map is the same as the number of physical vertical pixels in your scrollbar. The more pixels you have, the more packets you can see. In other words, if you use Wireshark regularly you now have a legitimate business case for a retina display.

Statistics dialogs. The dialogs under the Statistics and Telephony menus have seen many improvements. The backend code has been consolidated so that most of Wireshark’s statistics now share common internal logic. This in turn let us create common UI code with many workflow improvements and a much more consistent interface.

I/O Graph dialog. You can now graph as many items as you like and save graphs as PDF, PNG, JPEG, and BMP. Graph settings stay with your profile so you can customize them for multiple environments.

Follow Stream dialog. You can now switch between streams and search for text.

General dialogs. Many dialogs now have context-aware hints. For example the I/O Graph and Follow Stream dialogs will tell you which packet corresponds to the graph or stream data under your cursor. Most of them will stay open after you close a capture file so that you can compare statistics or graphs between captures.

If you want to see a live demonstration of the new UI, Laura Chappell and I are presenting a webinar next week on the 12th at 10:00 AM PST. You can register at http://bit.ly/wireshark2.

The final 2.0.0 release should be available in a couple of weeks. I’m excited about the new UI and about the opportunities that it provides for new features and further improvements.

Cool New Stuff

Hello everybody, we’ve got a handful of miscellaneous announcements for you today. They all just happened to occur within a handful of days, so it made more sense to lump them all into one post.

  • Development version 1.99.1 was released, another milestone on the road to 2.0 and our shiny new Qt interface. You can read the full announcement with release notes here, and download it from the “Development Release” section of here!
  • Tweet tweet! That’s right, we have an official twitter handle now for announcements and the like. It is shared by several of the core developers, but mostly run by our fearless leader Gerald. Follow us @WiresharkNews to find out more!
  • Thanks to the hard work of our Debian maintainer Bálint, we now have an Ubuntu PPA (Personal Package Archive) containing the latest stable Wireshark releases pre-built for all the supported Ubuntu releases. If you’ve ever wanted the latest and greatest Wireshark on an older version of Ubuntu, now’s your chance, so get it here.
  • Last but not least (although this one’s older – it actually launched way back in June), our repository now has an official github mirror. Please note that this is a convenience only; pull requests and issues will still go through our existing Gerrit and Bugzilla sites. The github mirror is very much *just* a mirror, but it is handy to have none-the-less.

That’s all we’ve got for you today, hopefully one or more of the above items caught your eye.

Wireshark 1.12 Officially Released!

We are proud to announce the release of Wireshark 1.12.0! This is a fairly significant release for us, as we expect it to be the very last release using the GTK toolkit in the default interface (see this post for our plans to replace it).

Wireshark 1.12 contains a substantial number of fixes and new features, representing just over a year of development effort. Check out the release notes for full information on what’s new and improved, and download it now!

If you have any issues with the new version, please file a report in our bug tracker.

To Infinity and Beyond! Capturing Forever with Tshark

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. Wireshark and tshark have long had a feature that lets you rotate your packet capture across multiple files, preventing any one file from getting too large; to do this, check out the “-b” flag to tshark. This was handy for systems limited in disk space, but did nothing for the ever-growing memory usage. A few days ago, however, I landed a change in tshark’s master branch that makes it discard its internal state every time the capture rotates to a new file. This has one huge benefit: you can now capture (theoretically) forever with tshark by using the “-b” flag!

Like any experimental change however, it does currently have a number of limitations:

  • State is lost when we switch to a new file, so if two fragments of the same message get split across that file boundary, they will not be reassembled. This is effectively unavoidable – while we considered discarding only very old state, this turns out to be extremely difficult with our current architecture. However, the result is that the dissection you get when capturing with “-b” should actually be closer now to the dissection you get when opening the individual files after the fact.
  • Discarding state can be a surprisingly expensive operation, so captures using this feature in high-traffic environments may see their dissection fall behind when switching to a new file. If you see this, please file a bug report with as much detail as you can provide, and we will try to smooth out the rough edges.
  • Memory usage might still grow a very small amount due to previously-hidden memory leaks now being much more obvious. Again, if you see anything problematic, please file a bug report.
  • This feature is limited to tshark only, it is not available in the graphical Wireshark interface. The graphical interface has to permit scrolling backwards to look at previously dissected packets, so it can’t discard anything until the entire capture is closed. (Edit: This isn’t strictly true – now that I’ve actually checked my assumptions, it should be possible to make the GUI behave the same way. It will take some additional work though.)
  • This feature is limited to the master branch only, it will not be in the upcoming 1.12 release. Given the substantial nature of the change, it was decided that it needed a chance to cook before being released as a “stable” feature. It is, however, present in the 1.99 automated development builds as of this morning.

Please test it out and let us know what you think. Happy capturing!

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:


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.

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.

If you’re using Windows, Mac OS X, or Linux Mint we need to support Windows, Mac OS X, and Linux Mint. If you’re using an iPad or a Galaxy Note we need to give you a long, hard, nonplussed stare and think about supporting IOS and Android at some point.

When I started writing Ethereal (Wireshark’s original name) it looked like this:


It looked like that on Linux and Solaris. It didn’t look like that anywhere else because those were the only two platforms we supported. I chose GTK+ for the user interface toolkit because it made the most sense. Compared to the options available at the time it had a number of advantages. It was small, light, easy to work with, had an active development team, and had a compatible license. A short time later we added support for Windows. GTK+ had some initial compatibility issues on Windows but it has gotten better over time.

Since then the platform landscape has changed but unfortunately GTK+ hasn’t. Most notably Mac OS X has gained popularity and people are starting to ask about Wireshark for their tablets. GTK+ supports OS X but it’s definitely a second-tier platform, making it hard to install and use. We either have to require X11 (like Inkscape) or use an experimental native GTK+ port (like GIMP). Either way it requires a lot of effort on the part of developers to produce a substandard application for users. With GTK+ Wireshark doesn’t look or act at all like a Mac OS X application:


Qt on the other hand provides a nice, clean user experience on all of the platforms that we currently support. If you install the 64-bit version it now looks like this:


What does this mean for users?

If you’re a power user you should probably keep using the GTK+ flavor for the time being. You should also test the Qt flavor from time to time to see how your workflow will change. Both are installed by default on Windows and Linux.

If you’re running OS X you should use the Qt flavor. For common tasks it should have a better workflow. Again, if it doesn’t we aren’t doing our job.

What does this mean for developers?

If you’re developing a new feature using GTK+ you should stop. You’re very likely wasting your time. If you would like to help with the migration grab the code and start developing.

What works?

Everything under the “File” and “Edit” menus.

You can capture, filter, and inspect traffic.

You can edit preferences.

You can follow streams.

You can view TCP stream graphs.

What doesn’t work?

Everything else. No capture options, I/O graphs, flow graphs, VoIP analysis, etc. We still have a lot of work to do.

Switching to Qt is a long and arduous process but I’m excited about what the future holds.

P.S. Solaris is still supported.


Wireshark Tutorial Series #2. Tips and tricks used by insiders and veterans

Yes, I know it’s been a while since tip #1 video (https://blog.wireshark.org/2012/10/wireshark-tutorial-series/?utm_source=rss&utm_medium=rss&utm_campaign=wireshark-tutorial-series) and this one. Judging by the number of views and comments, it is helping. So keep me honest by reminding me to post more often!

In this short video (http://www.youtube.com/watch?v=aIiosBw2YH4), I discuss the dangers of using default values without fully understanding what the consequences are. In Sharkfest 2013, Christian Landström gave an excellent session on the reassembly feature of Wireshark. Unfortunately, it wasn’t recorded and I wanted to convey the message. The PDF of his excellent session can be found here:  http://tinyurl.com/lko37zb


Hansang Bae

Fifteen Years

Fifteen years ago I released a little network protocol analyzer. At the time it wasn’t very special. It only dissected five protocols and only ran on Linux and Solaris. I decided to share it with the world and released it as open source. I made use of quite a bit of open source software at that point (and still do), and it seemed like a good way to give back to the community.

Immediately after the release an amazing thing happened — I started receiving code from people around the world. They had problems similar to mine and were able to modify the little analyzer to suit their needs. They were also kind enough to contribute those modifications back. Those contributions haven’t stopped to this day and Wireshark has grown into a mature, feature-rich, award-winning network analysis tool. People around the world use it to troubleshoot networks, develop software and protocols, and to learn about networking.

Wireshark has been a source of pride many times over the years but I’m particularly proud of two accomplishments. First, your network is not a black box. This is important inasmuch as our daily lives depend on networks operating efficiently, reliably and securely. Wireshark lets you peer into your network and see how it operates at a low level. It’s also accessible. Anyone can download and run it. Protocol analysis is a fascinating world and if you don’t understand what you’re looking it we have a large community of users and educators that can help you.

Second, it turns out that a protocol analyzer makes a great open source project and Wireshark is an example of open source at its best. People who know a lot about protocols are typically know how to write software. If you provide a platform that allows them to give meaning and context to the bits and bytes that make up network packets they will do so on a massive scale. Wireshark now supports over 1,000 protocols and 140,000 different protocol fields and those numbers keep growing.

We’ve had quite a few challenges in the past and we still do. These days all of your interesting traffic is either off in the cloud or speeding across your LAN at multiple gigabits a second. Wireshark doesn’t run on my tablet and it looks awful on my Macbook. However, these are solvable problems and I’m looking forward to the challenge of fixing them.

When I made that first release I had no idea how big it would become or how much it would impact my life. Wireshark is a great and wonderful thing due to the following people:

  • The development team, who seem to generate an endless stream of brilliance and cleverness.
  • The user community, for their knowledge and enthusiasm, and for putting up with the odd wart here and there.
  • Educators, researchers, developers, and everyone else who help people peer into their networks.
  • My employer for sponsoring the project and being such an awesome place to work, and my co-workers for their passion for network performance.
  • My family and friends, for their support and encouragement over the years.

It’s been a wonderful journey so far and I can’t wait to see what lies ahead. Thank you all.

Troubleshooting the hidden dangers of TCP’s Nagle algorithm and delayed acknowledgement

As we all know, TCP/IP is a great protocol suite.  However, there are times when it can become the bottleneck.  This is especially true if you use TCP/IP for real time transactions where small data sizes are the norm (think financial institutions).  In this session, I’ll show you why Nagle algorithm and delayed acknowledgement was developed.  But more importantly, I’ll highlight the unintended consequences when the two features interact – badly – with each other.  After watching this session, you will be able to spot the hidden dangers of using TCP/IP for real time transactions.   Enjoy, and as always, I would really appreciate your feedback and suggestions. Here is the video:

And as always, any and all feedback and suggestion are welcome.  Thank you and Enjoy!

Hansang Bae

Wireshark Tutorial Series. Tips and tricks used by insiders and veterans

For those of you who have attended Sharkfest in the past, you already know that protocol analysis is near and dear to my heart. It’s also a field where experience and art still matter. As great as Wireshark is as a tool, it still takes coaxing by an analyst to ferret out root cause. And as networks and applications become more complex, keeping up will be challenging.

But the one thing that I noticed over the years is that people rush to install sniffers without really thinking about it. It’s almost as if people expect sniffers to magically spit out the root cause, served on a silver platter! In reality, it takes fair amount of protocol and application knowledge to truly bring a tool like Wireshark to bear.

I started posting to this blog so that I can help budding protocol analysts and perhaps show interesting tricks-of-the-trade to veteran users. To become good in this field, it takes a fair amount of practice. It takes practice to know how to capture the right data, where to capture the data, what filters to use, and how to interpret the data. So how do you go about getting started? First, you can watch the accompanying video/tutorial session (see below for the link.) Next, make sure you setup your Wireshark in a consistent manner – the video tutorial covers this.

Ever wonder how router jockeys like me can scroll through a “sho run” output so quickly? It’s because I’ve done it for so long that the eyes are trained to filter out unneeded information. That’s the key to training – knowing what to filter out so your brain can get to work on the important stuff. It turns out protocol analysis works the same way. You have to train your brain to filter out the noise. Setting up your Wireshark environment will go a long way to maximizing productivity.

There is no “right way” to setup Wireshark. There’s only “my way” and everyone else’s – by definition – is wrong! Some like destination address to be the first column just like in DOS Sniffer. Others prefer using Wireshark’s default order. Whatever your style is, make sure it’s consistent. And if you’re just starting out, perhaps you can benefit from my setup. Even Anthony Bourdain in his book “Kitchen Confidential” talks about “mise-en-place.” It’s a term used by chefs and signifies how the cooking stations are setup. It’s important because it makes them more productive. For the same reason, you need to develop your own Wireshark mise-en-place!

If you still have not modified the default layout of Wireshark, you’re definitely missing out. In the video, I’m going to help you setup Wireshark so that you can become more productive. And we’re going to embark on a journey where I show you all the secrets to protocol analysis. I’m like the “magicians’ tricks revealed” guy. I’m going to help make you a rock star – where protocol analysis is concerned – in your company. If you’re an industry veteran, don’t be alarmed. The first few sessions are geared towards beginners so they can catch up. After that, I promise you that we’ll be in the weeds!

Hope you enjoy it, and I’d love to hear your comments. You can reach me at [email protected]