Is my 802.11ac wifi AP beamforming ?

I wanted to see whether my 802.11ac AP (Aerohive AP230) is beam forming. I enabled explicit beamforming. 802.11ac only supports explicit beam forming because 11ac beam forming is based on channel measurements which both the AP and the client need to support.

First thing, make sure the single user beamforming is advertised by the AP in beacons, I did this packet capture using wireless diagnostics tool of MacBook. 

Make sure that client supports single user beamforming in association request,

Now how do I know whether the AP is using beamforming when transmitting packets to a specific client. I was thinking I can check the SNR at the same client with and without beamfirming enabled. But every time you check RSSI or SNR at a client it keep changing, so it wouldn't really be a convincing test result. The next way to do this is to look at a packet capture to see whether the AP is using explicit beamforming procedure and transmit packets with wlan_radio.11ac.beamformed bit set to 1. The process for explicit beamforming is as follows,

You can see the packets for steps 1, 3, 4, 5 of the diagram above, but not step 2. Step 2 is NDP (Null Data Packet), this frame does not have a 802.11 mac header, it is only a physical layer packet. I think this packet is not passed to upper layers by wifi driver and that is why Wireshark does not display it. The packet capture below shows that the AP is using the beamforming process and sending frames using beamforming.

pkt capture  - Download pkt capture

Using LDPC in wifi

Wifi use forward error correction, in 802.11n(HT) and 802.11ac(VHT) LDPC codes were introduced as an option. The AP advertise whether it supports LDPC by setting the LDPC bit in HT capabilities information element,

pkt capture : https://drive.google.com/file/d/0B3ctVg8ubiwUSXo1NnlnVjVuSG8/view?usp=sharing

 If the client is able to use LDPC code it will set the LDPC bit in association request

The AP will respond with LDPC bit set to 1 in association response.

Once this is done the AP and the client can send pkts coded with LDPC to each other, whether a pkt is coded with LDPC or not is indicated in 802.11 radio info,

Multicast and broadcast pkt acknowledgement in WIFI

*** 8/4/2017 revision : This multicast frame is acknowledged by AP because the ToDS bit is set in the pkt, it seems.

I have read in several books and online that multicast and broadcast are not acknowledged in wifi. Those are encrypted using GTK and since there is no acknowledgment of these frames it is unreliable. Some wifi vendors has implemented multicast to unicast feature to deliver multicast packets reliably to wifi clients. But when you look at a wifi packet capture no ACK for multicast and broadcast is only half true. The wifi client send multicast and broadcast traffic as wifi(L2) unicast to the AP encrypted by PTK rather than the GTK. And the AP acknowledges this packet, and then the AP broadcast/multicast this packet to all the other wifi clients as wifi(L2) broadcast/multicast encrypted with GTK and the clients do not need to acknowledge these packets.

A packet capture of this would like like below,

The packet below is a multicast packet set by a client to the AP and the AP needs to acknowledge. As you can see the packet is addressed to the AP and it is encrypted using PTK.

Then the AP send this packet as a multicast to all the clients and clients do not need to acknowledge.

Wifi roaming controller vs controller less

One of the wifi deployments I worked with had an issue of RADIUS pkts received out of sequence. When client roam from AP-1 to AP-2, AP-2 sent accounting start first and then the AP-1 sent accounting stop. The wifi deployment was controller less, when the client roam to AP-2 the AP-2 immediately sent the accounting start, but the AP-1 which the client roamed away from took a little bit longer to realise that the client was disconnected and the the RADIUS accounting stop was sent later. This caused issues with the single sign on system because it depended on RADIUS accounting pkts to determine whether a client was connected or disconnected from the wifi network.

The conclusion about the above behaviour was that this is normal for controller less architecture. This lead me to test the same scenario with a controller based solution and the result is below. You can see that the accounting start and stop is used only when the client is disconnected from the network, when the client was roaming only accounting interim updates are sent. Controller based systems has several disadvantages like the controller being a single point of failure and a bottleneck when it comes to 802.11n/ac but roaming seems to be one of the things controller handles well.

 

Perform a wifi roaming test in LAB

Some time I need to make wifi client roam from one AP to another to reproduce issues reported by customers. This is not really straight forward if you don't have a large area to setup two access points and walk far enough so that client may decide to roam naturally. A workaround would be to make two shielding boxes and place the two APs inside the boxes. Open one and close the other. The client will connect to the AP in the opened box. To make the client roam to the 2nd AP, close the fist box and open the 2nd box :-)

I made the shielding box using a plastic box and aluminium foil, apply several layers of aluminium foil for better shielding,

If you leave your AP in default settings the client will not really roam as the transmit power of the AP is too strong to be shielded by aluminium foil. Therefore we need to adjust few things to make sure that the roaming test is successful,

1) Reduce the transmit power of the AP to minimum. The example below is from Aerohive HiveManager(cloud.aerohive.com),

2) Lowering Tx power is not enough, you should also disable all the lower data rates except for 54Mbps. Clients usually roam based on SNR. With lower power to be able to use 54Mbps data rates the client need high SNR and will roam easily as you open and close the boxes' lids,

Wifi RADIUS accounting packets out of order

I received this packet capture from a customer. According to the IT admin the AP was sending RADIUS accounting interim updates after RADIUS accounting stop message. I looked at the packet capture and it actually was true, there was a RADIUS accounting interim update after the client was disconnected. I started the investigation,

I used the filter (radius.Calling_Station_Id == "70-48-0F-63-6B-D1") && !(radius.code == 1),

I had to explain why there was an interim update after accounting stop, and I started by comparing what is the difference between this accounting stop and accounting interim update. Those were sent from the same AP for the same calling station ID mac address. After comparing the RADIUS attributes of the two packets I found something inserting. 

In the two packets the radius.Connect_Info is different, in the accounting stop the value is 11ac which is 802.11ac , therefore the client disconnected from 5GHz. Then the accounting interim update has the value 11ng which is 802.11n/g, therefore the client has connected to 2.4GHz in the same AP. To explain what happened clearly I added a new column in Wireshak with filter radius.Connect_Info,

Wifi capture has no unicast data frames

Capturing wifi off the air is challenging. Even after purchasing a tool like Airpcap you can running in to other mysterious issues like you can see wifi management frames but no data frames.

Lets start with Airpcap adaptor. Its a great tool, you plug it in to a Windows PC and appear as an interface in Wireshake. Simply set the channel and start capture. It is the easiest way to do an off the air capture. BUT ... you will realise that you don't see unicast data packets in the capture. Here is an example of me trying to capture a 4-way handshake using Airpcap adaptor, interestingly I could only see 2/4 and 4/4 message,

*** 4/4 message is displayed as 2/4. I have reported this bug to Wireshark [Bug 11994]

Then I did the same capture directly from the AP using remote capture function in the AP and I checked what was difference in 1/4 and 2/4 messages. It turned out that the AP is sending those messages using 802.11ac data rates. Airpcap adaptor is only 802.11n and was not able to listen to the 802.11ac transmission which was using 256 QAM.

This was the same reason why I couldn't see any data packets when capturing communication using Airpcap. All QoS Data packets were sent using mcs rates,

A really good tool to capture wifi packets is MacBook. Depending on the model you will be able to capture 802.11ac traffic. I am using a MacBook pro 13" retina with 802.11ac 3x3:3 wifi  for this example. Search and open "Wireless Diagnostic tool", set the channel and start capture. The capture will be saved to desktop with extension xxx.wcap. Simply change the extension to .pcap and open with Wireshark. Filter 

I entered by wifi SSID PSK in to Wireshark, therefore the data packets are decrypted by Wireshark.

To be fare to the Airpcap adaptor I setup an 802.11n AP and tried to do a capture to see whether the Airpcap adaptor will be able to capture QoS data frames. For this test I am going to use a 2x2 AP because Airpcap is a 2x2 adaptor.  Still Airpcap is not really able to capture any unicast data traffic.

Same AP and client captured using Macbook wifi diagnostics tool is able to capture unicast traffic,

Wifi off the air packet capture using Aerohive APs

I am sure you have seen many articles about how to use a Cisco AP as a wifi sniffer or use airmon-ng and Alfa AWUS051NH, or macbook wireless diagnostics tool. It seems like not many people are using the Aerohive APs' remote pcap feature which is a fantastic tool that capture and forward pkts directly to Wireshark.

*** Use a newer AP like AP121, AP130, AP330, AP370, AP230.

You need a Windows PC with Wireshark , only winpcap supports the remote capture function. If you already have an Aerohive deployment just find the AP and enable remote sniffer from the HiveManager,

If you want to use an AP as a standalone sniffer, you need to power up the AP using a 12V 2A power adaptor and connect it directly to a windows PC using ethernet cable and follow the instructions below,

1) Connect a cisco console to the AP and monitor the console output while pressing and holding the reset button,

2) Login using default username/password admin/aerohive and set an IP address

interface mgt0 ip 192.168.100.2/24

3) Enable remote sniffer

AH-016e80#exec capture remote-sniffer promiscuous 

sniffer device eth0sniffer started.

sniffer device eth1sniffer started.

AH-016e80#

4) set the radio channel you want to listen to

AH-016e80#interface wifi0 radio channel 6     --> to set the 2.4GHz channel

AH-016e80#

AH-016e80#interface wifi1 radio channel 36   --> to set the 5GHz channel

AH-016e80#

5) connect the AP to a Windows PC using ethernet cable


6) Set a static IP in the PC in the same subnet as the AP's IP address

7) Start capture from Wireshark,  These steps are the same when enabled remote sniffer using command line interface or HiveManager,

Start the capture ,