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.
