I have always thought that capturing wireless frames on several channels must have been done with several NIC-adapters in monitor mode. I have seen several pictures and videos showing 4, or even 8, adapters in a usb-hub, each capturing on a single 20MHz-channel.

But last week I used my WLANPi and the script from Nigel Bowden to capture on a 80MHz-channel. And what do I see when capturing at UNII-1 with 4 APs, each at 20MHz and using channels 36, 40, 44 and 48

Beacon from all 4 APs

In Wireshark each beacons radiotapheader reports channel 36, so thats little misleading. This is the channel you use when starting the script. But the HT Information Element in the beacons carry primary channel information, so using that as a colum it’s easy to see that I am capturing at every 20MHz-channel in the 80MHz-space.

This figure shows those four beacon with the same SSID where the radiotap header report channel 36, while til primary channel in HT IE report its correct channel

To check if I could capture roaming between those four APs I did a simple test.
– 4 AP in my office, 20MHz, channel 36, 40, 44 and 48
– associate my test client to the SSID
– waited til the test client was associated. On Android, Network Analyzer from technet is very useful to see the association status and associated channel
– disabled the AP the test client was associated to
– waited til the client had roamed to another AP
– and so on

This figure shows the (re)association request and (re)association response. As we can see, the test client roamed between all four AP. The (re)association response also carry the HT Information Element and its primary channel

Remarks
This is a simple test in a very low congested environment and the likelihood for a simultaneously transmisson in each BSSID is low.
If the RF environment are higher congested the likelihood for collision at the capturing device is higher, even it’s not a collision inside the BSSID. So we must assume that the capture could miss some frames.

If you want to test this by yourself, here is the link from Nigel Bowden for the WLANPiShark

• Nigels blog article:  WLANPiShark: Wireless Capture With a WLANPi on Windows
• Nigel at Github, script and user guide WLANPi upgrade: github

 

I hope this is useful

 

 

My recent blogpost was a theoretical approach using Ekahau ESS to find out if its possible to use Cisco WLCs TPC algorithm to set Tx-power on my access point according my predictive design in ESS

My design was based on Cisco 2802i access points, primary/secondary coverage -67dBm/-75dBm, Tx-power at 25mW/14dBm and 5GHz only

My conclusion from the theoretical approach was that the WLC would have problems with a consistent Tx-power setting. But I would give it a try

The access points was installed at theirs correct place and everything was default on the controller.

Ciscos RRM white paper uses the WLC CLI command “show advanced 802.11a summary” to show both Rx_neighbors and Tx_neighbors. On my WLC that command had a shorter output

So I used these two CLI-commands on the WLC

• show advanced 802.1a txpower
  • That command gave me allowed power levels and it showed that 17dBm was Tx_max
• show ap auto-rf 802.11a <ap name>
  • That command gave me nearby APs. How other AP hear us = Rx_neighbor.
  • Since each AP was represented with it base BSSID with hex-value “f” at last digits it became some work with excel to find corresponding 3´strongest Tx_neighbor

I will not show that excel-spreadsheet, but I will summarise it

Next table show the RSSI_3´strongest and Tx_ideal from my predictive approach and measured values on the WLC
Remarks: I used Tx_max =20dBm in my last blog. The value of Tx_max is adjusted to 17dBm

RSSI_3´strongest and Tx_ideal from predictive and WLC-output datapoints
Tx_max = 17dBm		RSSI_threshold= -70dBm
	Predictive			WLC output
	3´strongest AP	Tx_ideal (dBm)		3´strongest AP	Tx_ideal (dBm) (calculated)
AP1	-91	38		-88	35
AP2	-80	27		-86	33
AP3	-82	29		-82	29
AP4	-78	25		-84	31
AP5	-72	19		-81	28
AP6	-74	21		-85	32
AP7	-74	21		-72	19
AP8	-73	20		-84	31

As we can see AP1, AP2, AP3, AP4 and AP7 is fairly close between predictive and what he AP has measured (less than 6dB difference), but for AP5, AP6 and AAP8 the difference is huge (9-11dB).
Since all APs had calculated Tx_ideal above Tx_max every AP used power level 1 (17dB)

Next was adjusting the RSSI_threshold in the WLC TPC algorithm from its default value at -70dBm to -80dBm.
Next table compare the predictive approach and the calculated values on Tx_ideal and corresponding Cisco power levels based on measured values

TX_ideal and power levels from predictive and WLC-measured datapoints
Tx_max = 17dBm		RSSI_threshold= -80dBm
	Predictive			Measured
	Tx_ideal(dBm)	Power level		Tx_ideal (dBm)	Power level
AP1	28	1		25	1
AP2	17	1		23	1
AP3	19	1		19	1
AP4	15	1		21	1
AP5	9	´3-4		18	1
AP6	11	3		22	1
AP7	11	3		9	3-4
AP8	10	3		21	1

As we can se from the table on measured values the only AP that should change its Tx_power is AP7, even if we adjust the RSSI_threshold to its absolute minimum. AP7 has its calculated Tx_ideal based on measured values at 9dBm and the WLC set it on power level 3 (11dBm)

This leads to that 7 of my APs transmit at max power level (17 dB) and only one of the APs in the middle of the floor reduces its power level. This it not a good wifi-network.

During my research for this blogarticle a find five youtube-videos from Jerome Henry where he goes a RMM deep dive, check references

Two key element he says is

• The TPC algorithm kick in when you have 3 AP-neighbors at -70dBm or higher (or your configured RSSI_threshold or higher)
• The TPC algorithm is only used to automatically lower your Tx_power. The Coverage Hole Detection  is used to increase your Tx_level

My design with -67dBm/-75dBm and Tx= 25mw is no way near the TPC-goal to have three AP-neighbor at RSSI_threshold or higher, especially those in the outer edge of the floor

Conclusion
To have APs with consistent Tx-power its two choice

1. Go for static Tx-power on the APs
2. Limit the TX_min/Tx_max in your RF-profile to the values you want

 

References

Cisco RRM white paper, 2018
Jerome Henry youtube-videoseries, 5 videos 
mrn-cciew rrm-blogposts

Part 3 in this blog series will be on DCA

I´ll be back

I started my wifi-career in 2016 with Cisco WiFi-Fundamental as self-study. While reading about Radio Resource Management (RRM), Transit Power Control (TPC) and design principles I wondered how the network and the controller (WLC) was able to set the transmit power (Tx) on each AP according to design requirement. Since then I have read through CWNP-programme, Cisco RRM white paper and some  Cisco Design Guides and recommendations. Two ECSE–courses has also been completed. One instructor recommended static design and the other recommended tuning of TPC/RRM parameters

Now I am in a process of designing WiFi in one of our buildings and I’m using Ekahau Site Survey and Planner (ESS) to design the wifi-network.

So I thought why not play with ESS to give me some theoretical datapoints so that I could predict a value for RSSI_threshold for my TPC settings.

The building is 4 floors, where only second floor will get proper WiFi-design. The floor is 41 x 36m (136 x 117ft). The offices is along the outer wall, some meeting rooms in the middle and a cantine in one corner. The office walls is drywalls and set to 2dB attenuation and walls in the centre is concrete wall (12dB).

Design requirement is

• Signal strength:  -67dBm/-75dBm
• Accesspoint: Cisco 2802i
• Some area don´t need coverage according to requirement, aka exclusion area
• Tx-power on access point during design phase at 14dBm or 25mW
• Designing for 5GHz, turning off enough 2,4GHz radio to have at least -67dBm from one AP at the entire floor. Eventually turn up 2,4Ghz TX-power so that only 3 2,4-radios is enabled
• Split SSID (separate SSID for 5 and 2,4GHz)

 

Design from ESS, showing secondary coverage and slider set to -75dBm

Cisco RRM White Paper tells that for TPCv1 the APs measures two different signal levels. RX_neighbor is how good the AP hear other APs during NDP-packet process and Tx_neighbor is how good other AP hear us. For TPCv1 calculations the Tx_neighbor level are of interest.

To find out this in ESS I turned up each APs power level at 5GHz to 20dBm or 100mW. To simplify this test lets assume 20dBm is maximum allowed power level in our regulatory domain. Then shift ESS to Signal Strength for Selected AP and turn one AP after another and simulate. I used the slider for signal strength and adjusted that so  the edge between want and don´t want area or between don´t want and don´t care  area touches the other APs. In this example below two access points, AP2 and AP8,  hear AP7 at -63dBm and AP5 a -74dBm
Remember to change ESS visualization heights to 2,4m. Default in ESS is 1m

Simulation of how each AP is heared on the other APs (Tx_neighbor) is gathered together in this table

	Tx  = 20dB / 100mW
		Receiver level, Tx_neighbor (dBm)
		AP1	AP2	AP3	AP4	AP5	AP6	AP7	AP8
Transmitter	AP1					-91	-65		-65
	AP2			-59	-95			-62	-80
	AP3		-59		-49			-82
	AP4			-49		-78		-76
	AP5				-76		-57	-72	-72
	AP6	-65				-57		-90	-74
	AP7		-63	-80	-76	-74			-63
	AP8	-64	-80			-73	-75	-64

Cisco uses the 3´strongest Tx_neighbor in it´s TPC calculations. This values is in bold text in the table above

The formula that Cisco use to find the ideal Tx-power level on each AP is

Tx_ideal = Tx_max + (RSSI_threshold + RSSI_3´strongest AP).
Tx_ideal = 20dBm + (-70dBm + RSSI_3´strongest AP)

Tx_max is maximum allowed Tx-power in the regulatory domain. In this test that level is set to 20dBm.
If we then use this formula to find the ideal Tx-level on our access point and use the default RSSI_threshold value from Cisco WLC (-70dBm) we have those Tx-levels on our APs

	Tx_ideal (dBm) with RSSI_threshold = -70dBm
AP1	41
AP2	30
AP3	32
AP4	28
AP5	22
AP6	24
AP7	24
AP8	23

As we can see in this table the WLC has calculated that each AP should have a Tx-level above Tx_max, so all APs will be set to Tx_max; 20dBm or power level 1.

This does´t fit our design requirement where Tx should have been 14dBm

Cisco WLCs can configure the RSSI_threshold between -50dBm and -80dBm in the RF Profiles. Default is -70dBm

Lets us reorganise our formula to give us RSSI_threshold based on fixed Tx level at 14dBm.

RSSI_threshold = Tx_ideal – Tx_max + RSSI_3´strongest AP.
RSSI_threshold = 14dBm -20dBm+ RSSI_3´strongest AP

	RSSI_threshold for Tx = 14dBm
AP1	-97
AP2	-86
AP3	-88
AP4	-84
AP5	-78
AP6	-80
AP7	-80
AP8	-79

Our calculated values for RSSI_threshold is between -78dBm and -97dBm, so lets try with RSSI_threshold to  -80dBm for all APs

Tx_predicted =Tx_max + (RSSI_threshold_configured + RSSI_3´strongest AP)
Tx_predicted = 20dBm + (-80dBm + RSSI_3´strongest AP)

Our Tx_predicted will then be

	Tx_predicted (dBm)
AP1	31
AP2	20
AP3	22
AP4	18
AP5	12
AP6	14
AP7	14
AP8	13

 

Now we are at least inside power levels that are useable for our APs, except AP1 and AP3. If we adjust these levels to useable power level in Cisco WLC (20/17/14/11 … dBm) we get these power level (in dBm and Cisco power level) that APs should stabilize at after a DCA restart

	dBm	Power level
AP1	20	1
AP2	20	1
AP3	20	1
AP4	17 or 20	1 or 2
AP5	11 or 14	3 or 4
AP6	14	3
AP7	14	3
AP8	11 or 14	3 or 4

But still only AP5, AP6, AP7 and AP7 will be at or near Tx-level from the design.

Conclusion from this very theoretical approach is that there is difficult to use the TPC algorithm and RSSI_threshold in the WLC to configure our WiFi-network according to our requirement.

Then we have three options

1. Let the WLC be at default config and pray for good result
2. Turn of TPC algorithm, aka static Tx levels
3. Tune TPC Tx_max/max for all APs in that RF-profile/AP-group to 14dBm

 

Uncertainties

• Real wall attenuations don´t match the design
• Tx_max is not 20dBm in our regulatory domain
• I am way off on understanding Cisco RRM/TPC
• ESS calculations are unreliable

Next step is to install the APs and play with the configuration in the WLC and test if my theoretical approach and practical test corresponds

I´ll be back

References
Cisco RRM White Paper, 2018

My last blog was about some flavours of fast secure roaming (FSR). Based on feedback from the community, especially from Nicolas Darchis (thanks), I´ve learned that its possible to enable fast secure roaming with both AKM-suite 1 (WPA) and AKM-suite 3 (FT over IEEE802.1X) on the same wlan (also possible with PSK). Cisco calls it Hybrid Mode

We can configure our Cisco WLC like this; enable Fast Transition and both 802.1X and FT 802.1X AKM-suite. The controller will warn you that some non-802.11r clients may not join this WLAN

If we now look at the beacons or probe responses (from the AP) it will contain both AKM-suites in the RSN information element and the Mobility Domain information element. Like this.

When a client wants to associate to this WLAN it will recognize those two AKM-suites and dependent of its own capabilities it will use one of these during association and re-association.
But why do we get the warning from the WLC during configuration and what about adaptive 802.11r. I have search on the web regarding this and found a Cisco support forum-case where Jerome Henry explains it, look here

A short brief (from that article)
It is basically 3 sort of clients (in regards to 802.11r)

1. Those that support 802.11r (802.11r enabled)
2. Those that not support 802.11r, but are not against it. They are 802.11r-compatible, but not 802.11r-enabled
3. Those that are allergic to 802.11r. They do not support 802.11r, and refuse to associate to any WLAN where 802.11r is mentioned, even if other methods are also allowed on this WLAN

Testing in lab
I tested in my lab-network with WLC-configuration mentioned earlier and the same network/method as my last article. My test clients are a Samsung A5 (pretty new but simple Android-smartphone), an older Sony Z2 (smartphone on Android), iPAD2 (iOS ver 11.2.5) and a Lenovo Windows-client with Intel 6205 NIC.
Packets captures the initial association to original AP and captures on target AP when client roams. Cisco WLC-code is 8.3.122
The result

Client	OS	Original AP	Target AP	Remark
Samsung A5	Android	open authentication, open association, 802.1X/EAP-authentication, 4-way handshake	open authentication, re-association with PMKID in RSNIE, 4-way handshake	802.11r compatible, but not enabled
iPAD2	iOS	open authentication, ft-association, 802.1X/EAP-authentication, 4-way handshake	ft-authentication and ft-reassociaton	802.11r enabled
Sony Z2	Android	open authentication, ft-association, 802.1X/EAP-authentication, 4-way handshake	ft-authentication and ft-reassociaton	802.11r enabled
Lenovo laptop with Intel 6205 NIC	Windows	open authentication/association, 802.1X/EAP-authentication, 4-way handshake	open authentication, re-association with PMKID in RSNIE, 4-way handshake	802.11r compatible, but not enabled

As we can se all client does fast secure roaming either with 802.11r( Fast BSS Transition) or Opportunistic Key Caching (OKC).
So what about category 3-clients that don´t bother to associate to this network. I haven´t find any overview over those clients. But best practice is to test your most important clients before implementation and if those weird client shows up they could enter a guest-WLAN.

What is the purpose of adaptive 802.11r
Cisco have a feature called adaptive 802.11r. Since my last blog I have wondered what the purpose of that, since enabling both WPA/OKC and FT on same WLAN works well. And again Jerome Henry in the same support forum case explains it best, look here

Adaptive 802.11r is a feature in a network where 802.11r is not enabled. With adaptive 802.11r turned on, iOS-devices will recognize 11r-feature and use FT.  The other clients continues as before.
802.11r/FT for all clients (hybrid mode) would then be implemented after we had controlled our clients. We can look at adaptive 802.11r as a “zero-risk implementation” of 802.11r that helps IOS-devices to roam faster, without checking 802.11r-compabilities on all the other clients

MacBook (macOS)
I have not tested MacBook (MacOS) thorough since I use my MacBook for packet capture through Airtool. My80211.com have a great article on roaming behaviour on MacOS. But I did a short roaming test on my MacBook and I notice that it will not roam fast although RSSI from my original AP was -84dB and the target AP was 1m away from the client.  It used several minutes before it roamed and that breaks with the -75dB rule I have learned earlier. So I have something to check

References

• Cisco support forum, look here
• my80211.com, look here

A week ago I passed the CWSP-test. My knowledge is mostly from reading study guides, configuration guides, blogs and go through some online practice test. But I admit that the best way to remember the theory is to see whats actually happens with a packet capture. My last blog was on how to do packet capture and using display-filter in Wireshark.

Now its time to have a look a Fast Secure Roaming (FSR) in a network with 802.1X/EAP-authentication
When I was writing this blog I leared a LOT, so some chapters has been rewritten more than once.
Its very briefly, mostly like a “note to self” (wifi-joke). And OK to share
The goal is to see what happens during roaming, not how fast each roaming method are

My network looks like this

Test methodology
My methodology was to have two APs, each connected to SW2 with 15m cat6-cabel. One AP (called original AP) at my office floor and the other AP (called target AP) outside in the hallway behind an elevator shaft. The APs was tuned to lowest possible Tx-power and static channel setting (channel 52 & 56).
I use Airtool on a MacPro to capture the wireless packets.

1. Start Airtool on the channel corresponding the AP at my office
2. Associate the test clients to the test-SSID. The APs lamp should turn to blue
3. Stop Airtool. The capture files saves at the desktop
4. Start Airtool on the channel corresponding to the AP out in the hallway
5. Switch places for the two APs and wait until the target AP lamp lights blue (client associate)
6. Stop Airtool
7. Merge the two files together in Wireshark
8. Remarks
   1. If I a want a capture for wired traffic between AP and WLC, or towards Radius-server, it´s possible to use SPAN-function on SW1
   2. Since I have to have two separate captures from Airtool some packets will be lost. I also use a Windows client with ComView for Wifi and a D-Link DWA-182 c2 USB-adapter on the original APs channel so I could see the frame at that channel continously
   3. You should mark each AP with which channel number  it´s on, otherwise you have to use application like WiFi Explorer for MAC, InSSIDer for Windows or WiFi Analyzer for Android to find out which channel is where
   4. If you test with both client in the same capture it´s advantageous to check connection status at the WLC (Monitor/Clients) to make sure both clients are associated/reassociated before you stop Airtool-capture

 

Whats the secret ingredient in Fast Secure Roaming (FSR)
The 802.11-standard defines a robust security network (RSN) and robust security network association (RSNA). A RSNA requires two 802.11-stations to establish procedures to authenticate and associate with each other as well to create dynamic encryption keys, the 4-way handshake. The 802.11-standard defines several RSNAs. The one that are interested is this article is the Pairwise Master Key Security Association (PMKSA). This PMKSA is the result after a successful 802.1X/EAP authentication exchange between the client (supplicant) and the authentication server. When the PMKSA is established the Pairwise Master Key (PMK), which is the seeding material for the 4-way handshake, is created on both client (supplicant) and authentication server (AS)

A unique identifier is created for each PMKSA, the pairwise master key identifier (PMKID). The PMKID is found in association request frame and reassociation request frames, and in FT action frames. A client can have established multiple PMKSAs, so a PMKID Count field specifies the number of PMKIDs. These two field are inside the RSN informations element

The PMKID is a hash function that combines the PMK, the clients MAC-address and the APs MAC-address (BSSID)

When Cisco wireless controllers (WLC) are configured to use 802.1X/EAP-authentication it will use a fast secure roaming mechanism called Opportunistic Key Caching (OKC). What happens during roaming when OKC is used

(very short from Sybex CWSP Study Guide)

1. Client associate and full 802.1X/EAP authentication. PMKSA#1 and PMKID#1 are created on client and original AP
2. The original AP caches PMK#1 and forwards PMK#1 to target AP
3. The client calculates a new PMKID#2 using original PMK#1, own MAC-address and target AP MAC-address. The client sends reassociation request to target AP with PMKID#2 in RSN information element
4.  The target AP calculate its own PMKID#2 based on PMK#1 and the MAC-addresses. If those two PMKIDs matches, the target AP sends a reassociation response frame back  to the client
5. Because the two PMKID#2 matches, both target AP and client have the same PMK (established in point 1), and reauthentication (802.1X/EAP) is not needed. This PMK, together with MAC-addresses and nonce, create new dynamic crypto keys (the 4-way handshake)

 

Testing
I tested two client devices towards different configuration of WLAN. The client devices is:

• Samsung A5 cellphone (Android). It has support for Opportunistic Key Caching (OKC), but not 802.11r (Fast BSS transition, FT)
• iPAD2 (iOS 11.2.5). Not support for OKC and have support for  802.11r

Next I will comments shortly each setup

Wlan with 802.1X/EAP, WPA2/AES and AP in local mode
The WLC will use OKC as it´s key caching method

• Samsung A5
  • Samsung A5 supports OKC
  • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the client sends PKMID in its reassociation request to target AP
  • Authenticator (target AP or WLC) calculate its own PMKID, those two matches and the original PMK will be used to seed 4-way handshake
  • Target AP send reassociation response to client
    • Whether the PMK already are at the AP or just on the WLC haven´t I found any unambiguously information about. It´s vendor proprietary
    • Cli-command debug client <Mac-adress> on controller give a lot of information
  • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.

• iPAD
  • iPAD don´t support OKC
  • Associate to original AP with open authentication/association, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the iPad dosn´t send PKMID in its reassociation request because the iPAD don´t support OKC
  • Full 802.1X/EAP reauthentication and 4-way handshake on target AP.
  • This is not fast roaming

This capture shows a standard 802.1X/EAP-authentication. Open authentication request/response, association request/response, EAP-authentication and the 4-way handshake

And here we have roaming with OKC. Open authentication request/response, reassociation request with PMKID in RSN information element (see packet detail), reassociation response and the 4-way handshake

Wlan with 802.11r (Fast BSS Transition FT) over the air enabled. AP in local mode
The WLC will use only 802.11r (Fast BSS Transition, FT)  because FT is set to enabled, not adaptive 

Is this mode the beacons and probe response frames will carry the AKM-suite = 3, inside RSN information element, and a Mobility Domain information element (MDIE). AKM-suite 3 is FT over IEEE802.1X. Client that don´t support FT will not understand this and will not associate to the AP/BSS

• Samsung A5
  • Samsung A5 dosn´t support FT, so it should not associate to network
  • Even that these client don´t support FT it will regularly send probe request frames with open SSID, so the SSID with FT will answer with its probe response
  • This probe response carry AKM-suite 3 (FT over IEEE802.1X) in RSN information element and Mobility Domain information element
  • Since client don´t support FT nothing more happens. No authentication/ association

• iPAD
  • iPAD support FT
  • Associate to original AP with open authentication request/response and FT association request/response, full 802.1X/EAP-autentication and 4-way handshake
  • The difference between open authentication/association response/request and FT authentication/association response/request is that FT-frames also carry  AKM-suite 3, mobility domain information element and Fast BSS Transition information element (FTIE)
  • During roaming four frame is enough to both reassociate and create dynamic keys; the FT authentication request, FT authentication response, the FT reassociation request  and FT reassociation response. Those frames carry all necessary information, especially inside Fast BSS Transition (FTIE) information element (nonce, key holder id (RxKH-ID),  to create dynamic keys
  • Since dynamic keys are created during these four frame 4-way handshake in not needed

Here is first the managements frames during initial association. Packet detail from association response with both Mobility Domain IE and Fast BSS Transition IE. EAP and 4-way handshake frames are left out

And the from the reassociation to target AP. FT-authentication and FT-reassociations frames, all containing Mobility Domain IE and Fast BSS Transition IE. No 4-way handshake

Wlan with 802.11r (FT over the air) enabled with adaptive 802.11r. AP in local mode
Because some client dosn´t support 802.11r,fast BSS transition (FT), Cisco has developed a method where client that support FT and client that dosn´t can associate to the same Wlan/SSID. It´s called adaptive 802.11r. This is supported with WLC running AireOS 8.3 or higher.
Client supporting FT will use FT during roaming, while client not supporting FT will use OKC during roaming

So how is it possible for clients thats support FT and client that don´t support FT to associate to the same WLAN/SSID?
With adaptive FT configured at WLAN beacons and probe response frames from the AP will carry AKM-suite WPA in the RSN information element. Thats equal to 802.1X with OKC (opportunistic key caching) in our network. This gives the non-FT client opportunity to associate with OKC
But those beacons and probe response frames also carry Mobility Domain information element. The presence of mobility domain information element tells FT-capable clients thats they could use 802.11r/FT when they associate/roam

Here is some packet detail from a probe response with adaptive 802.11r/FT enabled. In RSN information element AKM-suite is WPA and the presence of Mobility Domain IE

• Samsung A5
  • Samsung A5 dosn´t support 802.11r, so it uses OKC.
  • Same method as Wlan with 802.1X/EAP, WPA2/AES and AP in local mode
    • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
    • During roaming, the client sends PKMID in its reassociation request to target AP
    • Authenticator (target AP or WLC) calculate its own PMKID, those two matches and the original PMK will be used to seed 4-way handshake
    • Target AP sends reassociation response to client
    • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.
• iPAD
  • IPAD supports 802.11r
  • Same method as Wlan with 802.11r (Fast BSS Transition FT) over the air enabled. AP in local mode
    • Associate to original AP with open authentication request/response and FT association request/response, full 802.1X/EAP-autentication and 4-way handshake
    • During roaming four frame is enough to both reassociate and create dynamic keys. The FT authentication request/, FT authentication response, the FT reassociation request  and FT reassociation response. Those frames carry all necessary information, especially inside Fast BSS Transition (FTIE) information element (nonce, key holder id (RxKH-ID),  to create dynamic keys
    • Since dynamic keys are created during these four frame 4-way handshake in not needed

 

Accesspoint in flex connect, 802.11r adaptive mode
If we use the access point in flexconnect mode it´s important to also configure flexconnectgroups. I have only tested with 802.11r adaptive mode, so that both clients can associate to the same wlan and successfully connect

Without putting AP in flexconnectgroup

• Samsung A5
  • Samsung A5 dosn´t support 802.11r, so it uses OKC.
  • Same method as Wlan with 802.1X/EAP, WPA2/AES and AP in local mode
    • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
    • During roaming, the client sends PKMID in its reassociation request
    • Authenticator calculate its own PMKID, those two matches and the original
    • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.

• iPAD
  • Fast Secure Roaming (802.11r) is not supported in flex connect mode without flexconnectgroups
  • Associate to original AP with open authentication/association, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the iPad dosn´t send PKMID in its reassociation request because the iPAD don´t support OKC
  • Full 802.1X/EAP reauthentication and 4-way handshake on target AP.

Putting AP in flexconnectgroup

• Samsung A5
  • Samsung A5 dosn´t support 802.11r, so it uses OKC.
  • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the client sends PKMID in its reassociation request
  • Authenticator calculate its own PMKID, those two matches and the original
  • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.

• iPAD
  • Fast Secure Roaming(802.11r)  is supported at access point in  flex connect mode with flexconnectgroups
  • IPAD supports 802.11r
  • Associate to original AP with open authentication and FT association, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming four frame is enough to both associate and create dynamic keys.The FT authentication both ways, the FT reassociation request  and FT reassociation response. Those frames carry all necessary information inside especially Fast BSS Transition (FTIE) information element to create dynamic keys (nonce, key holder id (RxKH-ID)
  • Since dynamic keys are created during these four frame 4-way handshake in not needed

 

Wiresharkfilters
I have used Wireshark as my protocol analyzer and have captured both wireless frames with Airtool and wired frames using SPAN-functions
Handy Wiresharkfilter are this one

• wlan.addr == <MAC-address to client>
• (wlan.fc.type == 0) &&! (wlan.fc.type_subtype == 8) ; all management frames except beacons
• eth.type == 0x0800. ; use it to filter out ethernet-frames (wired frames)
• wlan.tag.number == 55.   Find all frames containing Fast BSS Transition IE
• wlan.rsn.akms.type == 3.  Find all frames containing AKM-suite 3 (FT)

 

Summary
This is a summary on how my client behaved under different FSR-mechanisms

	802.1X/EAP	802.11r	802.11r adaptive	802.11r adaptive	802.11r adaptive
AP mode	Local mode	Local mode	Local mode	Flexconnect without flexconnect-groups	Flexconnect with flexconnect-groups
Samsung A5	OKC	not associate	OKC	OKC	OKC
iPAD	no fast roaming	FT	FT	no fast roaming	FT

Depending on how you configure your network clients behave differently. So its important to know your clients and as a wise man tells “Understand the protocols you work with” (Brian Long)

 

References

• Sybex CWSP Study guide
• Cisco Optimized WiFi Connectivity and Prioritized Business Apps
• Other Cisco configuration guides

Read More »

How to capture frames in Wireshark on a network with WPA2 Enterprise and AP in FlexConnect using MacBook

My lab network looks like this

Remarks
– SW2 with AP, trunk against AP with vlan 1716 (ap management) and vlan 2000 (flex WLAN), 1716 as native vlan
– SW2, all vlans enabled on all trunkports
– Router, two LAN-subinterfaces and internal dhcp-server for both subinterfaces, nat against internet
– Radius-server (authentication server). Ubuntu-client. Free Radius server, configured for EAP-PEAP and EAP-MSCHAPv2
– WLC (authenticator): Wlan with wpa2-aes and 802.1X, access point in flexconnect with native vlan to 1716 and the flex WLAN mapped to vlan 2000
– Android smartphone (supplicant). Mac-address on wifi-nic: 5c;51;81;22;4d;a1

Traffic flow

The traffic flow in this network is like this

• Phase 1: Establish 802.11 data link: probe request/response, authentication and association between the client and the AP
• Phase 2: Starts with the authenticator (WLC) sends request identity to the supplicant (client) and the supplicant respond. The virtual uncontrolled port on the authenticator opens and allow EAP-traffic through (the red line). An important part of this process is the traffic flow between the authenticator and authentication server (the blue line)
  • Part 1 is the authentication of the client. It ends with an Access-Accept from the authentication server to the authenticator and EAP-Success from the authenticator to the supplicant
  • Part 2 is creation of crypto keys  (4-way handshake). When the last message (message 4 of 4) is acknowledged the virtual controlled port authenticator opens and traffic from the client will flow directly to the router in the flex-vlan
• Phase 3: The supplicant (client) is authenticated and crypto keys are generated. The client is now able to start the dhcp-process and all traffic flow in the flexconnect-vlan directly to the router (the green line)

 

Capturing frames
I want to capture these frames
– between the wireless client (client) and the access point (AP), in the air
– between the AP and the controller (WLC)
– between the WLC and the radius-server
– between the client and the router when the client are authenticated and crypto keys are generated (ordinary traffic)

To manage that we have to capture into the air and at SW1 port g1/0/14 and g1/0/28
I am using Cisco equipment so it´s possible to use SPAN-ports (port mirroring). Some switches will not distribute vlan-tags natively on SPAN-port so I had to configure it. The commands on the SW1
– monitor session 1 source interface g1/0/14 , g1/0/28
– monitor session 1 destination interface g1/0/3 encapsulation replicate

To capture the wireless frames I´am using a MacBook Pro and Airtool from Adrian Granados.
The packet analyser is Wireshark

Start capturing
MacBook connected to SW1, g1/0/3, via ethernetport
The client wifi-nic either deactivated or connected to another SSID. It´s also best to “forget” the actual SSID on the client so that we are sure the client have to go through the hole 802.1X EAP-process

– Start the capture in Wireshark on your ethernet-port
– Start wireless capture in Airtool at the channel your SSID are transmitting
– Activate your client on the flex connect SSID and log on with your username and password
– Wait until the wireless client is connected
– Stop capture in Wireshark and Airtool

Merging capture files in Wireshark
Airtool will automatically save the capture on your desktop. Save your wired capture from Wireshark to the desktop.
Clean your window in Wireshark with File/Close.
Drag the two captures from Desktop into Wireshark. Now the two captures will merge together and since they both uses the same clock from the MacBook all the frames will be stacked in the correct order

Time to filter important frames
With our setup the capture will consist several frames from the same transmission, from the capture points.  The capture can consist of several 1000s frames depending of which type of traffic there is on the network, especially if we had captured from a production network. We will use display-filter in Wireshark to filter out those frames of interest.

Filter wireless frames
It is one address that are important to find, the Mac-adress of the wireless client. It can be found in different ways. Either from Utilities on the client, from an app like Net Analyzer on the wireless client or from one of the captured frames. In this example  we will find it from one of the frames

1. Find one of the wireless frames in your capture. The easiest way is to filter on EAP. Make sure that you find a wireless frame. If you have columns with Data Rate or Signal Strength those should show a value. Go into IEEE 802.11 packet details in Wireshark and find your wireless clients Mac-address, either as receiver address (RA),  transmitter address (TA) or destination address (DA). Right click and prepare or apply as filter. To make sure to show frames in both direction change either “wlan.ra”,  “wlan.ta”  to “wlan.da” to “wlan.addr” like this
   
2. If you apply that as a filter the capture will show all management, control and dataframes to and from your wireless client except the ACK-controlframe from your wireless client towards the access point. This frame, which acknowledge unicast frame from the access point to your wireless client, only have one address which is the receiver-address of the AP. It´s difficult to filter out the ACK specially from the your client to the AP, so we filter out all ACK-frames with this filter
3. If we filter on those from 1 and 2  the capture will still show frames from the wired side. To make sure to only see wireless frame we have to find a filters that only show wireless frames. One alternative is the Data rate parameter from the 802.11 radio information section.  Select this and change it to show 1 Mb/s or higher (all possible data rate
   
4. Bring it all together and it will show all wireless frames between the wireless client and the AP
   
   or like this
   

Filter Frames between the AP and the Controller
Almost all the frames in the phase where the wireless client are contained into the virtual uncontrolled port of 802.1X-EAP process that goes between the AP and the controller. These frames are tunneled inside the Capwap-tunnel. To filter out these we could use the filter from above with some modification. Change the filter to show frames from the wired side, i.e. frames not containing “wlan_radio.data.rate”. Change “and” to “and not” Like this. .
This view shows all traffic on the wired capture points between the client and the WLC, inside the capwap-tunnel.
If we now make a filter that combine all together we could use this 

Filter Radius-frames between the controller and the Radius server
This one is quite easy. It´s just to filter on “Radius”

Filter for all the frames when the authenticator has the virtual uncontrolled port open
With this filter we are able to see all frames from the client joins the SSID and to the client are authenticated and crypto key are generated

Filter on ethernet-frames
During authentication, association, EAP-authentication and 4-way handshake all traffic to and from the wireless client goes inside the control-tunnel between the AP and the controller. When the client is authenticated and all crypto keys are generated (4-way handshake) the client will be moved from the virtual uncontrolled to the virtual controlled port of 802.1X-process and traffic will moved over to the vlan for the flex connect-SSID. Since the SSID on the AP is in flex connect, all traffic will flow in the flex connect vlan between the AP and the gateway-router, and not through the controller.
Those packets can be filtered by using the clients mac-address, but now we have to filter them as ethernet addresses. The best way to find those packet is to find the IP address for the client after  the dhcp process. Either by looking at the dhcp-server, at the wireless client or filter in Wireshark with “bootp”. Or just search for other frames with the assigned IP address. When one of these frames are found, look into the ethernet packet detail and find the mac-address for the client. Here we also have to change the filter to show frames in both direction. The filter should look like this

The final filter in Wireshark
Above are the filters for each type of frames we are looking for (frames of interest) during the WPA2 Enterprise authentication process. Bringing it all together we will have a Wireshark-filter like this

or

What we have
With the last filter we will see at lot of frames. When the client is inside 802.1X-EAP virtual uncontrolled port the same transmission is seen in three different frames.
– between the client and the AP, wireless frame
– on the trunk between SW1 and SW2
– on the trunk between SW1 and the controller
– and vice versa

When the wireless client are moved over to the virtual controlled port in 802.1X-EAP process the same transmission will be seen twice
– between the client and the AP, wireless frame
– on the trunk between SW1 and SW2, towards the router
– and vice versa

Note: since we have two capture files that are merged together it could happen that the wireless frames and the wired frames have changed order.

What is it possible to find
With those filters it should be possible to find all frames of interest during
– probe request/probe response
– authentication/association
– 802.1X-EAP authentication
– 4 way handshake
– DHCP
– ARP
– normal traffic to and from the Internet.

How to do it in Windows
I have used MacBook Pro and Adrian Granados Airtool to capture wireless frames. To do the same in Windows it is more difficult since Windows can´t natively capture wireless frames in promiscuous mode. But amyengineer.com and sniffwifi.com have blogarticles on howto capture wireless frames with Acrylic wifi

 

 

 

 

I need som tips from the wireless community with a challenge I have

Background
I was preparing a blogarticle about transmit power mismatch impact on datarates when I discovered that my Windowsclient was transmitting  dataframes towards the AP with 2 spatial stream (mcs 8-15), while the AP only transmit with 1 spatial stream (mcs 0-7) toward my client.
No matter how near those stations was eachother the same transmit-pattern happened

Clientdata
The client is a Lenovo X-320 with Intel advanced-n 6205 wireless nic. Drivers version is 15.18.0.1 from 30.april 2015. Window 10

Wireless infrastructure
I have tested the client against Cisco 2602i and Cisco 2702i accesspoint both in centralized, flex connect and autonomous mode. And towards different network, both our production and two different wlc-labnetwork. And with WPA2 Enterprise, WPA2 Personal and Open authentication

Other moments:
– The wlc has almost default configuration except TPC, level 3
– The RSSI on both client and AP/WLC is appr.  -60dBm
– No CCI, tested on 5GHz, channel 36, 40 and 44
– 20 MHz channel

Examination of frames
I have studied management frames, association request and association response, and both enables mcs 0-15 under HT Capabilities element, RX Supported Modulation and Coding Scheme.
And I can’t find anything else that should tell me that the AP only transmit mcs 0-7

Wireless NIC driver
I have find a nic-driver with version 19.70.0, but the client refuse to install that. It says that 15.18.0.1 is the best nic-driver
A google-search on that wireless-nic only displays problems with installation

So the condition should be good enough so that the AP could transmit with 2ss
When I test with a 2ss tablet (iPAD), both stations transmit with 2ss

 

Question to the wireless community
– Is this a common problem with that wireless nic (Intel advanced-n 6205)?
– In which wireless frame and information element  should I find that this happens?
– Any solution?