How to add a certificate to trusted root certificates using group policy - Windows 2008 R2 / WPA2 Enterprise PEAP

I create a new set of RADIUS certificates for an Aerohive AP which is configured to be the RADIUS server. MacOS ad iOS clients prompt the users to accept the new certificate but Windows does not. There are two way to get around this,

1) Install the root CA certificate the local machine and select the folder trusted root certificates,

Double clock on the certificate








2)  Add the CA certificate to the group policy 

WMM admission control in action - VoWiFi

I was working on troubleshooting a VoWiFi issue and was doing some pkt captures. It was interesting to see the packet flow of how the phone setup  a traffic stream when the user answer the call.

With Spectralink 8440 & Aerohive AP330

Call flow when wireless multimedia admission control is used is given below, 

  Pkt capture sample

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,