Whistleblower Blog   by Chris Bloom

I am throwing down the gauntlet! Hands down, WildPackets OmniPeek has the best protocol decoders on the market, and alway will. OmniPeek decoders are an interactive, extensible, and tightly integrated part of the application, and that is what I am going to focus on today.

I have been writing decoders for over 9 years, and I have seen a lot of decoders. Some are good, and some are really bad. But WildPackets decoders are great. First of all, they are a pleasure to look at. The color schemes and layout are very nice, and help to distinguish the various layers and fields of a packet. They can also be copied and pasted into other applications, and they can be saved to a file in numerous formats including text, html, and rtf.

I have heard through the decoder grapevine, that decoders have become a commodity. In some ways, maybe that is true, but my conspiracy theory is that most analyzer companies do not want to invest in their decoders anymore, because they need to develop and offer new products. We understand that protocol decoders will always be at the heart of protocol analysis, so we continue to invest in our decoders, and our unique decoder technology.

When comparing decoders, most people talk about the number of protocols that an analyzer supports. This number is important, and OmniPeek sports a huge number of them. In fact, according to our support website, OmniPeek decodes over 1,000 protocols and sub-protocols. However, every company counts their decoders differently, and some just get silly, claiming to decode many thousands of protocols. Well guess what, there really aren't that many protocols out there anyway, and of the total list, most are esoteric, and will never occur on your network. So really, the protocols you have on your network are supported by most analyzers. What really matters is how well the decoders are integrated into the rest of the analyzer, and how this helps you troubleshoot and solve network problems. And that my friend is where OmniPeek breaks through the clouds, and shines like the sun on a beautiful day.

When it comes to decoder integration, my all-time favorite feature is the Decoder Column in the packet list. The Decoder Column is off by default. This may be because it is simply too powerful for mortal men and women. But, if you want to be all that you can be, go ahead and turn it on. This is achieved by right clicking in the packet list headers, moving the cursor to the bottom of the menu, and enabling the Decoder Column. Once the Decoder Column has been enabled, every decoder field in every protocol layer, can be viewed in the packet list for every packet, at the same time. This is a mouthful, and might take a moment to sink in. But when you get it, you will realize how huge this is.

No other protocol analyzer has this type of tight integration with its decoders. What this allows you to do is see a decode field, or a whole decode layer, for multiple packets at the same time. This makes it much easier to compare decoder field values for different packets without having to select a packet, and look at the decode, and then select another packet, and look at the decode, and what was the value of the first packet again?

With the Decoder Column, the number of fields in the packet list are virtually infinite. But how can that be? Infinite is a very large number, right. Ah, that is where it gets interesting. In OmniPeek, decoders are not compiled into the program. No, no, no. In OmniPeek, the decoders are written in a special decoder language, that is optimized for protocol decoding. The decoders are in files that end with .dcd and are read from the decodes directory. This means that you have access to all of the source for all of the decoders.

But this is unlike open source, because you do not need to spend thousands of dollars on a compiler to modify Omni decoders, or even know what a compiler is. Instead, when OmniPeek runs, it reads the .dcd files automatically. This means that you can add new .dcd files, and change existing .dcd files all you want. The more decoders you have in the decode directory, the more functionality you are adding to the product. OmniPeek users do this all the time, for all kinds of reasons. It is a huge differentiator, and again illustrates the tight integration that OmniPeek has with its decoders, and in general the extensibility of OmniPeek that I am always raving about.

The Decoder Column is not the only way in which decoders are leveraged in OmniPeek. Searches for packets can also be done on the decoded text of the packet. Some folks are not aware of this, because the UI to access this functionality is maybe not as obvious as it could be. But basically, go to the Edit Menu, and choose Find Pattern. In the Find Pattern dialog, select "Decoded Text", and type in the label or value that should be in the decoded text of the packets you want to find. Again, because of the extensibility of the decoders, the number of fields you can search for are virtually infinite.

Ok, let's say you're convinced, and have decided to change a decoder, enhance a decoder, or write your own. As I mentioned before, there are many reasons to do this, which I will not focus on here. Instead, I will go full circle, back to the Decoder Column. This is because when you do stuff to the decoders, you are extending the program in numerous ways. We call this synergy, and it is some powerful mojo. By adding new decoders, or even fields to an existing decoder, you are adding new fields that can be displayed in the Decoder Column. This is why the number of fields in the packet list are virtually infinite.

I know, most people will not actually write a decoder, but if you need to, you can. Also, this is how WildPackets is able to stay ahead of the decoder games, and whip them out as quickly as we do. This is also what separates the decoders from the core product, so that new decoders and decoder fixes can be released periodically, without having to release a new version of OmniPeek. For example, in our Custom Engineering Division at WildPackets, we often write custom decoders for our customers. When we do this, the deliverable is simply a .dcd file, not a whole new release of OmniPeek.

For those folks who do write decoders, WildPackets offers a visual decoder debugger called Decoder Studio. It is on the WPDN, and is free for maintenance customers. Decoder Studio was modeled after the look and feel of Microsoft Visual Studio. It allows you to step through the decoders, one line at a time, and see the decode appear bit by bit, as the packets are being decoded. While stepping, you can see the code, the stack, variables, and lots other state. For a decoder guy like myself, it as indispensable tool. There are many other features in Decoder Studio that I won't go into detail here. If you want to try it out, head over to http://wpdn.wildpackets.com and download the Decoder Toolkit, from the Tools section of the Downloads page.

Have you tried the Decoder Column? What did you think? Have you written a decoder? How was it? We would love to hear about your experience, and any feedback or suggestions you may have about our decoders.

Two years ago, WildPackets released the first version of the Google Map Plug-in for OmniPeek. It was an instant hit then, and continues to be the most downloaded plug-in on the WPDN.

The Google Map Plug-in is free, so that is a pretty good reason to at least try it. But more than that, it is a compelling mash-up of two very useful applications. Since then, WildPackets has released a virtual army of Google Map downloads, including two OmniPeek Google Map Plug-ins, a remote Google Map client for the OmniEngine called OmniMapper, and a very simple to use, standalone Google Map application called PlaceMap. Ok, so that's only 4. Still, it is more Google Map applications than most companies have.

In case you don't know, the OmniPeek Google Map Plug-in maps the locations of network devices to the Google Map. Different colored markers are used to represent network devices, where each marker has a color that specifies the amount of traffic from a device. By clicking on a marker, a balloon appears with more information about the IP address. In the balloon, there are also helpful links that will take you to websites with more information about that IP address. The websites include DShield, Whois, SpamCop, and SenderBase.

This week, WildPackets posted a new version of the Google Map Plug-in, as well as a new version of the PlaceMap application to the WPDN. The new Google Map Plug-in is sporting a new look, with a fancy tool bar, and much better marker drawing. PlaceMap has all of the new features of the plug-in, plus it runs all by itself. No OmniPeek necessary. Of course, running within OmniPeek provides much more information about the network. But for high level monitoring, PlaceMap is a good place to start.

The Google Map Plug-in is what we call the good map. It represents all network traffic, or at least the traffic that can be mapped from an IP address to GPS coordinates. This is great for some types of monitoring, but when it comes to network troubleshooting, most IT people are only interested in the bad map. This is the map that displays network devices that are experiencing unacceptable levels of latency. In OmniPeek, we call this an Application Performance Index or APDEX score, and when a users APDEX score exceeds a certain threshold, an event is generated. Sound interesting? Well, we wrote a song about it. Actually, it is a plug-in called the APDEX Google Map. It is the “bad map”, and only maps nodes whose APDEX scores have exceeded the specified threshold.

But ah, you have an OmniEngine? Or even better, you have multiple OmniEngines, running at different sites? Hmmm, then you should try OmniMapper. OmniMapper is a standalone Windows client that aggregates nodes from multiple distributed OmniEngines, and maps them all to the same Google Map.

And this is just the tip-o-the-berg. Who knows what we will do next. Actually, I do. :-} But if you have any requests, please let us know.