pointer

Tag Archives: access points

The Challenges that Arise in Monitoring 802.11ac Equipment

In our last blog post, we wrote on the Wi-Fi Alliance’s 802.11ac certification program and how it helps both the consumer of wireless equipment as well as the distributor of wireless equipment.

This week, we want to focus on the process of monitoring your new 802.11ac equipment once it’s installed. Before you can monitor 802.11ac traffic, you need to be able to capture the traffic. This is true regardless of the monitoring solution used, and capturing 11ac traffic remains one of the biggest challenges with this new technology.

Let’s take just a moment and step back to see how this has been done with 802.11a/b/g/n. Wireless LAN monitoring did not come without its struggles in these bands either, but over time the industry settled into a comfortable solution using laptops with 802.11 USB WLAN adapters. This solution is highly portable, making on-site WLAN analysis easy, regardless of the location. Most solutions work with only a subset of available USB WLAN adapters, and some require a custom adapter. In either case, the key requirement is that the WLAN adapter be able to be put into “promiscuous mode,” sometimes called sniffing mode. If this capability is not exposed in the device, then it has no chance of being used as part of a WLAN network monitoring and analysis solution. This combination remains as the “go-to” solution for most WLAN analysts, both in the field and in corporate WLAN environments.

So, what’s changed in 802.11ac? Let’s take a look at a few key differences between 11ac and previous technologies that are making WLAN monitoring and analysis more difficult.

Timing/Availability
Let’s face it, 802.11ac is brand new, and with that comes all the issues of timing and availability that may not always coincide with a perfect and logical order. Hardware vendors need software to test the new devices. Software vendors need hardware to test their software before they can provide it to hardware manufacturers. It is a classic “chicken and egg” scenario. As we described earlier, WLAN analysis software needs supported WLAN USB adapters to collect data for analysis. Without supported adapters, the software cannot be developed and tested, at least not fully. This is starting to ease, as more adapters from more vendors are starting to hit the market, some of which are compatible with promiscuous mode and can be used for wireless packet capture. As with previous 802.11 specifications, the situation will improve, but it’s always a painful process at the beginning.

Breaking the “Gigabit Barrier’
802.11ac is the first wireless standard to break the “gigabit barrier,” delivering wireless connectivity at data rates in excess of 1Gbps (in some modes). If you recall, it wasn’t all that long ago (OK, at least for us old guys) that we were talking about 1Gbps wired speeds. Breaking through this barrier requires some adjustments in the way we capture and analyze wireless data. First, back to our USB WLAN adapters. The key word here is “USB.” The laptops most of us have probably support USB v2.0. That means a maximum theoretical throughput of 480Mbps, with a practical limit less than 300Mbps. The slowest typical 802.11ac connection will be at 433Mbps (1-stream and 80MHz bandwidth). So it’s pretty clear that USB v2.0 is not up to the task. USB 3.0 will do in most cases, but you need to make sure that both your laptop and your 802.11ac WLAN USB adapter (that is compatible with your analysis software) are USB v3.0 compliant. It’s looking like some hardware upgrades may be required soon…

And it’s not just about the devices. Network analysis at greater than 1Gbps can be very demanding in terms of CPU and memory, and the software itself must be up to the task. Many are not; we already know this. Fortunately our OmniPeek network analyzer is up to the task since it’s been doing multi-gigabit wired analysis for many years now.

There are alternatives to USB WLAN adapters for capturing data, and we highly recommend that users begin thinking in this direction. The best approach is to use an AP to capture wireless data. APs are typically more capable than USB adapters (think more streams and better optional feature support) so they are best suited to the task. If you use the same brand for capture that you plan to use to send data, then the feature set compatibility will be guaranteed. Again, just as with USB adapters, you need to ensure that the AP can be put into promiscuous mode. Most enterprise APs can (but not all), and most consumer-grade APs cannot. Remote Pcap support is the best bet for using an AP as a packet capture device. We know, this makes portability a bit more of an issue. You may need to find a plug and be a bit more stationary when capturing data, so you can plug in your AP “sniffer.”

Staggered Feature Roll-outs
The 802.11ac specification is still in draft form, and the biggest risk at this point is equipment that doesn’t yet support the feature set you expect, even if the feature is “required” by the spec. The Wi-Fi Alliance (WFA) has just started interoperability testing against the draft spec so this should help a great deal in eliminating the uncertainty, but until the specification is ratified any equipment you plan to buy to be used specifically as part of a WLAN analysis set-up should be carefully researched to be sure that it will meet both your immediate needs as well as those down the road after ratification.

802.11ac shows major promise in the industry, but getting yourself ready to be able to monitor and analyze the new equipment is a bit of a challenge. Patience is essential in this process, as is ensuring that the solutions and equipment you buy will be compatible with a long future of 802.11ac wireless analysis.

Best Practices for Capturing 802.11ac Traffic for Analysis

The traditional method used when capturing wireless data for analysis has been based on consumer-grade WLAN USB devices. In most enterprise networks, network engineers use USB 2.0-based WLAN adapters since this is what is typically available. However, with the increased speed of 802.11ac, this method becomes troublesome.

Why?

802.11ac introduces data rates that exceed 6Gbps – faster than most wired speeds. Even the most sophisticated USB devices based on USB 3.0 (the latest standard) have a theoretical bus speed of 5Gbps, with an effective rate of about 3.2Gbps. So even USB 3.0 does not provide sufficient performance for capturing peak 802.11ac data rates, and every packet counts when it comes to wireless analysis.

In order to effectively and efficiently capture and analyze your WLAN traffic for analysis, you’ll need to look to another device to help you – access points (APs). Using APs as packet capture devices is hugely beneficial because the APs in your network are typically specified to handle the most capable clients that will connect to your WLAN – guaranteeing that you’ll have the capacity to capture whatever traffic is on your WLAN.

Wireless packet capture from APs can be accomplished using two different, but similar, approaches. The first is using remote PCAP (RPCAP) and the second is using custom remote adapters.

Capturing Packets with Remote PCAP (RPCAP)
PCAP is the de facto standard for capturing packet data on a network (wired or wireless) and allows interaction with remote devices to capture packets. In order to capture data for analysis on a remote device, it must be running the RPCAP daemon (rpcapd).

There are two modes that can be implemented when using RPCAP – a passive and an active mode. Active mode will try to establish a connection to the analyzer; the analyzer then sends the appropriate commands to the daemon and starts the capture. This method requires the WLAN itself to have knowledge of when it wants to start an analysis session, and this is beyond the capability of most WLANs today, leaving the active mode as an interesting but mostly untapped capability of RPCAP, especially for wireless analysis.

For this blog, we’ll focus on the passive mode, which is the most common and the simplest. In passive mode, the analyst directs the analyzer to the devices to be used for packet capture by providing the IP addresses of the device(s). The analyzer then connects to the remote daemon and is provided a list of available interfaces that can be used for packet capture. The analyst then selects the interfaces of interest and starts a capture just as if that adapter was connected locally. All channel and band choices are made directly on the AP, or through the AP controller software.

Now, if you are interested in this type of capture method, your next step is to find access points that support RPCAP. This feature is not easy to find, as it is not necessarily a “marketed feature” by manufacturers. That said, we have already tested RPCAP for wireless analysis using several devices, including:

  • Aerohive: Model HiveAP 120
  • Ruckus: ZoneFlex 7363 (requires ZoneDirector Controller)

Many other AP manufacturers have told us that they also support RPCAP across most if not all of their AP offerings. If you know of other specific products with this capability, we’d love to hear about them.

Capturing Packets using Custom Remote Adapters
With custom remote adapters, the APs directly deliver data to the WLAN analysis software. This feature has been a part of WildPackets technology for a while and we have custom adapters to collect from Cisco, Aruba, and Meru APs. The process for developing a custom remote adapter is very similar to that of RPCAP but it requires a little more interaction between network analysis software vendors and hardware equipment manufacturers since the tunnel used to send the packets between the AP and the analysis software is proprietary to each equipment vendor and therefore requires a “custom” adapter.

Now, in order to get this system set up, go into your controller software on your AP and pick either an AP or a radio and put these into promiscuous mode. If an access point has multiple radios, you can put some in promiscuous mode and leave some in network mode so user connectivity is not affected. Most enterprise installations have sufficient wireless coverage so even if you take a few APs and put them in promiscuous mode, network performance will not be degraded. Once this configuration is done, you provide the controller with the IP address where your WLAN analysis software is running, and the AP immediately begins streaming packets to the analyzer. Now simply start your capture on the specific custom remote adapter and begin analyzing.

Remote adapters in general provide another benefit besides being capable of performing packet capture for the most demanding networks. They also allow analysts to capture packets for analysis anywhere in the network – worldwide – without leaving their desks. WLAN analysis requires that packets be captured within a few hundred feet of the area where the problem is being reported. There’s no way around this. Now that 802.11 technology has become so popular, problems can be happening anywhere, and it is not feasible to have an analyst close enough to every installation to be able to just walk over with the network analyzer and collect data. Remote adapters provide the flexibility to capture WLAN data anytime and anywhere.

The Basics of Wireless Channel Aggregation

You’ve bought the controllers, the access points (APs), the VoIP Phones – the entire infrastructure required for wireless – and while all of these pieces worked well together during the testing phase, when people in your company start using wireless, a variety of problems begin to pop-up. Problems such as: dropped VoFi calls, low signal strength, and connectivity issues.

So the question now is: why does everything seem fine during testing, but malfunction under real world conditions?

One of the answers may be that you do not have adequate visibility of your WLAN set up. Specifically, in today’s highly mobile environment, it is not enough to monitor each channel of a WLAN independently. As wireless users move around, or roam, they typically transition from one AP to another and from one channel to another; and, it is often these transitions which cause serious issues for wireless-based application use.

To adequately monitor, analyze, and troubleshoot your WLAN you must collect data across multiple channels simultaneously for visibility when users roam. At WildPackets we call this channel aggregation. With traditional wired network analysis, there’s only one “channel” in use, so channel aggregation is a function that is unique to WLAN analysis.

Wireless channel aggregation is relatively straightforward, if not widely available. Most WLAN analysis products scan through the channels of interest to compile overall statistics for WLAN performance. Scanning creates gaps in the data, and the more channels scanned the bigger the gaps. This technique, though adequate for generating statistics, falls far short for detailed analysis and root-cause resolution. For example, let’s say your WLAN uses 10 channels. Because the data capture is only on one channel at a time, you are only receiving 10% of the data on any single channel. This means that you’re blind to 90% of the activity on that channel, woefully inadequate for detailed analysis. This is especially true for analyses that involve critical timing, like roaming. Roaming should take place within a few hundred milliseconds, or less. If you go back to our 10 channel example, and assume that the dwell time on each channel is 0.5 seconds, then you will have a 5 second gap between times when data is collected on any given channel, and this is obviously inconsistent with the millisecond granularity needed to detailed timing analysis.

Wireless channel aggregation gets us past these problems. All that is needed is an analysis solution capable of receiving data from multiple channels simultaneously, and enough wireless adapters to cover each of the channels to be analyzed. The data is then captured into a single analysis session, and you have all the data from all the channels and can perform any level of detailed analysis that’s required.

Now that you have a better understanding of wireless channel aggregation, you can be better informed when looking for solutions capable of true root-cause wireless troubleshooting. At a minimum, we suggest that these tools be able to capture wireless packets from multiple channels simultaneously (without scanning) and measure vital statistics on each channel separately, as it provides you with a better understanding of the activities happening on each channel. Additionally, having a wireless channel aggregator that calculates latency of devices roaming between access points is also very helpful.

For more details on what is out on the market, and the hardware and software needed to perform wireless channel aggregation, check out this whitepaper by the Certified Wireless Network Professional titled The Triple Blendy.