Google Maps Mania

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.

Throwin’ Down The Decoder Gauntlet!

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.

Free can be very expensive

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!

WildPackets and Extensibility

In my previous blog entry, I gave a history lesson on the rise and fall of the NetGen Empire, and why being acquired by NetScout won’t help either of them. Although there are many reasons why this will be the case, a glaring lack of APIs and extensibility, an area near and dear to me as a Developer Evangelist, is an obvious one.

In sharp contrast to the closed box mentality of the NetScout and Network General applications, is WildPackets’ OmniPeek product line. WildPackets continues to innovate with major new releases, each one improving on every aspect of the technology, including the gorgeous user interface. With the most recent release of the OmniPeek 5.0 product line, WildPackets became the first vendor to offer 802.11n wireless analysis. This is huge, and nobody else has it.

As a solution, the OmniPeek product line has API’s coming out of its ears, a developer network with 3000 members, a developer website with all kinds of useful extensions and source code, and a full-time Developer Evangelist and Custom Engineering Team. The plug-ins and source code on the WildPackets Developer Network, also known as the WPDN, are free to maintenance customers.

As the needs of WildPackets’™ customers change, the API’s allow the products to be extended to meet those needs. Two examples of this are automation and analysis. Many companies use OmniPeek to test their own products, which they do over and over again. With WildPackets API’s, the analysis on the back-end can be developed as plug-ins, and the tests themselves can be automated through API’s on the front-end.

These API’s have allowed WildPackets to integrate and partner with other vendors like Cisco, Aruba, and AirTight. These companies offer Access Points and Probes that can be used by OmniPeek to collect packets from different channels of the wireless network. What’s more, the API’s allow packets from multiple probes to be aggregated in real-time into a single capture. This solution, called Multi-Channel Analysis (MCA), allows engineers to perform roaming analysis and other types of analysis across channels. This measurement, up till now, has been a laborious and time consuming task that wireless engineers have performed by hand.

And the list of integration partners goes on and on, particularly in the area of wireless cards, where OmniPeek has more support for different wireless cards than any other vendor.

The most famous and innovative example of integration is the Google Map Plug-in, which maps the IP addresses captured by OmniPeek into the Google Map. However, the biggest demand is for application layer viewers for email, instant messaging, web pages, and so on. The API’s make it possible for WildPackets to keep up with the application layer viewing needs of its customers without changing the core product.

To aid the developer community in the creation of plug-ins for the OmniPeek product line, WildPackets has developed a Plug-in Wizard that integrates with Microsoft Developer Studio. This wizard generates plug-ins, with source code, allowing the developer to quickly create plug-ins, over and over again. This makes rapid prototyping and development of custom solutions easy and cheap.

Although scripting and plug-ins are the two primary ways to extend OmniPeek, other API’s are available as well, and I will be talking about them in the future.

Going once, going twice … Network General, sold for only $205M !!!

NetScout just picked up Network General at the auction house for only $205M. Their intention is obvious, lacking in deep packet analysis themselves; they are trying to round out their product offering with a protocol analyzer. On that account, who can blame them? But with what? Network General’s Sniffer software is antiquated. While software and user interface technologies have come a long way, especially in light of Web 2.0, Network General has not had a major release of Sniffer in 7 years. The only real value in this purchase is their market share, and certainly not the technical leadership that customers should require.

While this might look good on paper to some, the problem arises when you realize that the real losers in this game of hot potato are the customers. Network General’s products are not cheap, and in the past NetScout sold a lot of expensive products to big Enterprise IT departments. And even though there are much better and less expensive products on the market, it is still hard to convince upper management to move on, and dump 20 years of investment. However, over time, as Network General has failed to keep up with the needs of the market, their customer base has been forced to supplement their tools with other vendor’s products. This has been necessary because Network General’s products are not extensible.

And this is why the acquisition of Network General by NetScout does not have any synergy. The two products are very different, old, and have no API’s. So how are they going to integrate? It will be hard, and if they do it will take so long, that in the accelerated time-space continuum of the network industry, others will step in and offer their customers better and less expensive solutions. The lack of API’s on both sides also makes it difficult for these products to integrate with other solutions and with each other. And if you read much about the industry today, companies want integrated solutions because they want greater ROI.

So in the end, who really benefits? Hopefully customers will realize that this is merely a fire sale and the cost of restoration is just too high. Rebuilding with open, integrated, and extensible solutions – like those from WildPackets – is far more cost-effective, both now and in the years to come.

To overlay, or not to overlay, that is the question

Most wireless networks evolve. They start out simple, with coverage in a few specific locations, like a conference room and the lobby waiting area. The network is used mainly by guests, so performance and reliability are not a focus – the network is a “nice-to-have” – and little or no network monitoring or troubleshooting is required. But employees become dependent on the wireless conference room access, and demand access from more locations and expect to have the performance and reliability characteristics of the wired network. The network grows, and so does the need for network analysis and troubleshooting. Given that the wireless coverage is still “spotty”, portable network analysis – like that provided by OmniPeek running on a laptop – seems to fit the bill. Eventually the wireless network grows to cover the entire workspace, and it becomes a viable alternative to wired access. At this stage the network requires 24×7 monitoring and analysis. This just can’t be accomplished with a portable solution. But with 20+ APs spread over 200,000 square feet, how can you be where the trouble is, and where it’s occurring?

<p>
The only alternative has been “overlay networks” – a system of wireless sensors deployed within your wireless network. This approach is expensive, with both a significant up-front cost for all of the sensors and their management software, and an on-going cost to manage this “management network” network. But now you have a choice – to overlay or not to overlay, that is the question. WildPackets AP Capture Adapters for both Cisco and Aruba allow any managed AP, or a number of APs simultaneously, to be put into packet capture mode, acting as sensors only when needed. Though this implies a slightly more dense deployment of APs, it is still far cheaper than an overlay network, and it provides tremendous flexibility for capturing wireless packets – you can collect from anywhere, anytime, with the click of a button. Typical high-quality, enterprise-wide wireless deployments are designed with overlapping wireless coverage in mind anyway, so often times no additional hardware is required. Using only the AP management console and WildPackets’ OmniPeek, you can monitor, analyze and troubleshoot your entire wireless network, using your existing hardware and without getting up from your desk.</p>

<p>
Interested? The WildPackets AP Capture Adapters for Cisco and Aruba are all you need to get started, and they are freely available from the WDPN.

</p>