Greg Crosby, network services manager for The Seattle Times talks about how he can look at multiple devices simultaneously and perform trend analysis across the network with OmniPeek. Prior to using OmniPeek, Crosby’s team had to “[plug] laptops with protocol sniffers into ports on individual network devices to analyze packet traffic.”

Recently, Crosby had an intermittent problem with their FTP server that would have been a mess to troubleshoot. “If we were using laptops, we would have had to put six laptops on [the network devices] and we would have had to centralize our captures and analyze each capture independently.”

Read the rest of Shamus McGillicuddy’s article on SearchNetworking.com for more details about how they solved this problem and how they use OmniPeek to fix network problems.

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.

Recently, WildPackets did a study on the growing cost of rogue network access, and found that this is a problem that 25% of IT managers are spending more than 10 hours per week trying to solve. For many companies, the amount of time and money spent on network security will continue to increase as the number of telecommuters grows to 100 million by 2008.

Why is this, and what can be done to avoid it?

The problem is simple. Instead of investing in the best commercially available training and tools available for the long term, many companies are looking to save money in the short term. One way to save money now is to invest nothing. This is very dangerous, and not recommended under any circumstance. By investing nothing in network security, a problem that exists and must be addressed, companies inadvertently spend more, in wasted time and software development that is outside their core business.

Here is how it happens. The IT staff, tasked with network security and no budget, will do what they can for free. This is an honorable thing to do, and in their defense will show how much they have done, with so little money. Free is a tricky term though. And in the end, free can be very expensive.

You see, “free”, in this context involves people spending time, often times developing software. This is a big red flag, and one that you should watch out for, and avoid. As we all know, time is money, and development requires a lot of both. Development includes creating tools from scratch, and using open source software, neither of which are free. On the contrary, they are investments, and expensive ones at that.

Just think about it. If your organization is a bank, a hospital, a branch of government, or even a database company, should it be investing in the development of network security software? Is that your core competence? Dare I say not. And by the way, finding an open source solution is not free at all. The many hidden costs including research, compilation, maintenance and training, all add up.

And when the local expert decides to leave the company, what do you do then? Who are you going to call? Not if, but when that happens, you are either going to continue sliding down the slippery slope of “free” software, or you are going to do what should have done in the first place, and buy WildPackets OmniPeek.

WildPackets has been at work, developing OmniPeek for every 20 years. If you add up the total hours invested, you get a very very big number. Trust me, this is a number of hours that you do not want to invest your own money into, for a problem that has already been solved. For a fraction of that price, IT can invest in and use OmniPeek to solve all of its network security problems. And when new IT staff come on board, trust me again, they will already know how to use OmniPeek. In fact, it should be on their resume.

WildPackets OmniPeek software and hardware solutions provide visibility into the entire network. WildPackets also provides training on network security and network troubleshooting. Investing in WildPackets significantly lowers TCO and increases ROI. To learn more, join in and listen to one of our regularly scheduled web seminars. Schedules and registration are posted on our home page.

Remember, packets never lie!