This document intends to present the basic procedure for capturing traffic using vWLAN. There are two distinct traffic capture features in vWLAN.
These packet captures are useful for troubleshooting a multitude of issues including 802.1x authentication and login failures. This guide assumes vWLAN can communicate with the BSAP and that Wireshark, or similar software, is available to open the generated file. AP traffic captures are run and initially stored on the AP itself. Because of the limited space on the AP, all AP traffic captures are limited to 2MB.
AP traffic captures will be explained in more detail later, but an important distinction must be made between the AP traffic capture types. A wireless capture will actually change the AP mode to sensor, and listen to traffic of other 802.11 APs and stations (STAs). In this mode, the AP cannot service wireless clients, but rather listens to 802.11 communications in the wireless medium (WM). The AP effectively becomes a wireless sniffer.
A wired capture can be run on the AP to which the client is actually connected. The wired capture type encompasses all physical interfaces on the AP, including the 802.11 radio interfaces. Basically the wired capture type shows standard network traffic processed by the AP itself.
vWLAN traffic captures are useful for troubleshooting Captive Portal Authentication, LDAP authentication, or sniffing any other traffic destined for vWLAN. vWLAN Traffic Captures are performed under Administration > Traffic Capture. In general, you will not need to filter these captures, but vWLAN does provide options should you need or desire to. The main option to notice is the Ethernet Interface. A vWLAN hardware appliance (not VMware) will have both a Public and Private interface. The Private interface is only used for management of the vWLAN. Typically there will be no need to capture traffic on this interface. For example, both Captive Portal and LDAP troubleshooting will use the Public interface. Most cases will require capturing on the public interface.
To start a capture, first set the protocol, or use the default of Any, then fill out any appropriate fields. Leaving a field blank means there is no filter. For example, selecting TCP as the protocol but leaving the Port blank means that all TCP traffic will be captured. After the desired fields have been filled out, simply click Start Capture. A capture file will appear below the form. Simply click Stop to end the capture, and the capture file should change such that download link is generated.
AP Traffic Captures are performed under Administration > AP Traffic Capture. Client traffic is not routed through the controller in vWLAN, so in order to capture wireless client traffic it is important to choose the AP Traffic Capture.
There are multiple settings in the AP traffic Capture many of which many are context sensitive.
A new vWLAN installation is in place, and clients appear to be having issues connecting. Further investigation shows that the clients are not being assigned IP addresses via DHCP. A test client should be selected in order to narrow the scope of troubleshooting. The client is connecting to the Guest SSID on the 802.11b/g/n (2.4 Ghz) interface as seen on the Status > Clients page. This page also shows which AP the client is connecting to as well as which Role and Location is being assigned to the user. All of the important information is enclosed in the image below and should be noted for future reference.
At this point, the client traffic needs to be captured to determine what traffic is making it out of the AP. On the AP Traffic Capture screen, select the AP’s name from the drop down menu. The capture type is “wired”, the interface is the “BG(2.4Ghz)” radio, and the SSID is “Guest”. Here we have also selected UDP as the protocol since DHCP uses UDP ports 67 and 68, but this is optional since most analyzation software will have robust filtering options as well.
Once the correct settings have been selected, click “Start Capture” at the bottom of the page. A status message will be display after the capture is started.
Clicking “stop” at the end of the status message will stop the transfer, and the information will be transferred from the AP to vWLAN.
The captured file must be downloaded for further analysis. The figure below shows the capture filtered on UDP ports 67 (bootps) and 68 (bootpc). Here it is seen that the client is sending out DHCP Discover messages, but there is no offer returning from the server. Looking more closely at the packet capture, it is seen that the client traffic is on the correct VLAN segment (802.1Q Virtual LAN … ID: 3) and is sourced on UDP 68 with a destination of UDP 67. DHCP starts out as a layer 2 broadcast (some people will also call this a UDP broadcast). The client sends traffic out with a destination port of UDP port 67 (sourced from UDP port 68), and the server responds with the destination being UDP port 68 (sourced from UDP 67). Additionally, when the server responds it may no longer be a broadcast; the traffic flow may become unicast depending on various flags. Regardless, from a firewall perspective this traffic flow might seem like two separate traffic flows, and therefore the client role must allow DHCP outgoing and DHCP-Server incoming.
In this example, the server traffic was not allowed in the role. Once the role was adjusted, the client was able to get an IP address
Wireless clients are reporting low data rates or dropped connections in a particular area. First, identify the AP(s) servicing the area and note both the BG and A channels as shown in the image below. There is also a Dynamic RF suggestion message which is good indicator that there may be RF related issues around that particular AP.
Retransmissions are a clear indicator of problems in the wireless medium, and a wireless capture will help determine if retransmissions are occurring. It is important to note the channel(s) the AP is using, because wireless captures require a separate device for capturing. In the case where a BSAP is used to capture wireless data, the BSAP that is capturing data cannot service clients at the same time it is capturing. That is why it is important to make a note of the channel(s) being used by the AP(s) in the area where the problem is occurring. We have over simplified our example such that BSAP2030 is the only AP available to service clients. All other APs are in Sensor Mode. So in this example, we note the following.
Again, we want to simplify this example so we will focus on just the BG radio. We do this because a 20 MHz channel width means we only have to capture on a single channel. Larger channel widths, for example 80 MHz, actually means there are 4 channels that we would need to look at. However, it is important to understand that concept when looking at issues with 802.11n or 802.11ac deployments using bonded channels.
Wireless captures require a separate AP for capturing purposes. Since all the other APs are in sensor mode, we simply select another AP on the system and choose a wireless capture type on BG channel 11 of the BG (2.4 GHz) interface. All of the other settings can be left at their defaults.
Start and the stop the capture as documented in the wired capture example. Typical wireless captures will reach the size limit pretty quickly, especially when beacons and probes are not filtered. However, it is useful to capture beacons at least once since it can confirm rogue networks causing co-channel contention issues. Further, most traffic analyzers have their own filtering features. For example, in the image below beacons and probes are filtered.
In fact the capture above is heavily filtered, but what we are looking for is retransmissions. Retransmissions in a wireless network are the result of a number of different problems, and their presence indicates a degradation in client throughput since clients have to send multiple copies of the same data. The screenshot above shows a retransmission of a device going into sleep mode.