I passed CWAP-403 and CWDP-303 few days ago. It has been a very rewarding study, but long and tiresome. I rushed to take the certifications before my study guides and practice tests expired at the end of October, and passed at first attempt.
CWAP is hard. I used the 2011 Wiley CWAP Study Guide as a foundation, then Matthew Gast 802.11ac Survival Guide, and the official CWAP-403 Study Guide. I did many packet captures and analysis, but the most useful inspiration and motivation came from following the WLAN community.
The practice tests were very valuable to gauge my readiness and motivate me taking the exam at last.
CWDP is often overlooked as an easy certification, perhaps because many people take it when they’re already advanced in the WLAN learning path. I used CWDP study for taking guilt-free breaks during the preparation of CWAP and it worked well for both certifications in the end.
I used the official Study Guide and the practice tests, but the real factor in passing this exam was the experience built up in my job as WLAN administrator and designer at my university.
Now I’m looking forward what to do next. On the cert/study line, an IoT exam like CWISA. Writing more on the blog, and giving back to the WLAN community, maybe by doing something local here in Europe/Italy.
Following my previous post on DFS, I’m testing a modern Extreme Networks AP410C with the Wifimetrix tool.
AP410C is a new cloud managed wi-fi 6 access point evolved from the Aerohive product line, now acquired by Extreme. Tested model: AP410C Rev: F, OS 10.1.3.0 (10.1r3).
As usual, the AP is on a DFS channel, Wifimetrix sends a simulated radar wave, and the packet capture is analyzed.
Test: channel switch
After detecting a simulated radar signal, the AP does not send a channel Switch Announcement action frame. It sends a beacon frame containing a Channel Switch Announcement information element with channel switch mode 1 (clients are not allowed to transmit during the switch), destination channel, count 8 (AP will switch after the 8th beacon is transmitted), last transmitted beacon count 1 (AP switching immediately before the next TBTT). This behavior is consistent, either with and without client stations associated to the AP.
AP410C on channel 52 detects a radar and sends CSA in beacons. It then switches to channel 64. See pcap for details.Channel Switch Announcement IE in the beacon.
Test: channel switch-back
The switch back to the original DFS channel happens after about 30 minutes and does not use any Channel Switch Announcement to inform the associated stations of the new channel.
AP410C on channel 64 switches back to channel 52. See pcap for details.AP410C on channel 48 switches back to channel 52. There are no CSA action frames nor CSA IE in beacons. See pcap for details.
I observed that when stations are associated to the AP, they keep transmitting on the same channel after the switchback, sending probes, retries, and eventually disassociating. I had a Windows10 laptop and an iPhone associated and streaming video (Youtube), both lost connectivity and did not reconnect to the original channel. Zero-wait DFS was enabled on the AP.
Impact assessment of channel switch
With AP410C it takes about 918ms (9 TBTT) from an initial radar detection to the move to a new channel, during which clients are not allowed to transmit (mode 1). This is way more that the maximum 150ms roaming hand-off time required for VoWiFi. I can figure out 2 scenarios:
The client station remains associated to the AP, the voice call will suffer degradation during the channel switch.
The client station decides to roam away to another AP, therefore voice calls and videoconferencing are not disrupted (provided FT is enabled or PSK is used).
Which of the two scenarios is more likely depends on the roaming decisions made by the client (if roaming is feasible at all, that is).
The disruption from a radar-induced DFS event is noticeable, but very limited and quickly recovered.
Impact of channel switch-back
After a defined amount of time on the new channel, the AP switches back to the original DFS channel without any announcement to the associated stations. There are two scenarios that come to my mind:
The AP implements Zero-wait DFS or a similar mechanism: a client station on the channel fails to receive frames from the AP (beacons, ACKs) and either:
somehow it discovers the AP on the new channel and moves, keeping the original association;
or it roams to another AP.
The AP performs a Channel Availability Check (CAC) before transmitting, the client station roams to another AP.
It is unclear to me how long the roaming will take, considering the time spent by the station sending retry frames, probes, listening to beacons on different channels. I tested an SSID on a single AP and experienced complete loss of connectivity.
My personal impression is that the channel switch back is even more disruptive to service than the initial radar-triggered channel switch. Where CAC is performed (without Zero-wait DFS mechanisms), service from the original AP is disrupted for 30 seconds or more.
Final thoughts
Mitigating the impact of DFS events seems to focus on roaming. Careful roaming design is called for, including secondary converage, 802.11k (which should be enabled anyway if DFS channels are used), Fast Transition and 802.11v.
I tested the DFS implementation in Extreme Networks legacy AP 3800 and 3900 series. Unfortunately, it does not implement channel switch announcement.
Upon detecting a radar signal, a legacy Extreme AP 3900 complies to domain regulation and leaves the 5Ghz channel where radar was received. It does so by sending deauthentication frames to the BSS and moving straight to a new channel. There is no Channel Switch Announcement in action frames or in beacons. The new channel number however can be defined in the controller configuration.
Affected devices
This issue affects legacy, controller-based 3900 and 3800 APs from the ExtremeWireless/Identify product line. It does not affect the recent ExtremeWireless cloud AP line following the Aerohive acquisition.
The following models were tested:
WSAP3935i-ROW firmware 10.51.170006
WSAP3915i-ROW firmware 10.51.170006
WSAP3912i-ROW firmware 10.51.170006
AP3825 firmware 10.51.170006
3900 are 802.11ac Wave2 APs that went out of sale in December 2020. They are supported through 2025 on the latest Extreme Campus Controllers (ECC).
3800s are an older 802.11ac Wave1 AP line, still supported until 2023 on legacy Extreme controllers.
I have not tested the 3900s from the WING product line. As far as I know it’s exactly the same chipset. If you are a WING user and use DFS channels, you should test.
Background
During a CWNA course in 2019, Devin Akin mentioned DFS validation and the wide differences in DFS implementation by vendor and by AP model. The DFS Project website has a good introduction to the issue and several example packet captures you can check out. The DFS Project lists a set of questions that the validation process should answer:
Does my AP detect DFS events of various types?
If a DFS event is detected, does my AP move to a new channel? If so, how long does that take?
Does my AP announce the Channel Switch Announcement (CSA) in beacons, probe responses, and action frames? If so, for how long?
If a DFS event happens, how does it affect application performance on my devices?
When my channel changes, where does it go?
Does my AP return to the original channel? If so, after how long?
After a channel change, what happens to the channels on the other APs in the area?
The Channel Switch Announcement information element is found in action frames and beacons. It provides a graceful transition mechanism to a new channel, while keeping the client stations associated. The clients are informed of the channel number and the move time. If the destination channel is U-NII-1 U-NII-3 (non DFS) the service disruption is minimal.
Tools
I used the Wifimetrix handheld wi-fi tester, which I finally purchased this year. It does many useful WLAN things, my favorite being the FCC radar wave simulation. I am under the ETSI regulatory domain, so the Wifimetrix manufacturers kindly provided me this FCC-ETSI equivalence table:
FCC ETSI
0 1,2
1 1,2
3 3
4 3
Test results
I configured Extreme APs 3935, 3915, 3912 and 3825 on a DFS channel on 5Ghz, and started a packet capture. I simulated a radar event on that channel with the Wifimetrix and analyzed AP behavior in the capture.
Leaving the channel
Upon detecting a radar signal, the AP sends broadcast and unicast deauthentication frames with Reason code: Deauthenticated because sending STA is leaving (or has left) IBSS or ESS (0x0003). It then leaves the channel for good.
The destination channel can be defined in the AP configuration as custom channel plan (legacy Identifi controllers) orDFS fallback channel (Extreme Campus Controller). It should be a non-DFS chanel so that the AP does not have to perform a Channel Availability Check (CAC) and can start transmitting immediately.
A 3935 AP on a legacy Identifi controller on channel 60 detects radar and sends a broadcast deauthentication frame. See pcap for full details.The above deauthentication, with reason codeA 3915 AP on a legacy Identifi controller on channel 56 detects a radar and sends broadcast and unicast deauthentication frames to each of the connected clients. See pcap for details.A 3912 AP on a new Enterprise Campus Controller, on channel 100. A radar event triggers unicast deauthentication frames. Note the beacon transmitted after the deauthentication. See pcap for details.A 3935 AP on a new Enterprise Campus Controller, on channel 104. A radar event triggers unicast deauthentication frames. See pcap for details.A legacy 3825 AP in channel 52 detects a radar signal and sends broadcast and unicast deauthentication frames. See pcap for details.
Switching back to the original channel
I have not tested this behavior fully, this are just my preliminary results with a 3912 on ECC. After about 1 hour the AP simply leaves the channel without any deauthentication of CSA frames.
A 3912 AP on channel 48 leaves and returns to channel 100. See pcap for details.
It is very likely that the AP will do a channel availability check before resuming transmission in the original DFS channel, but I have not tested it yet.
Impact assessment
The DFS mechanism implemented in this APs effectively disrupts service to the client stations in the basic service set.
Leaving the channel
When the AP detects a radar signal it send deauthentication frames to the BSS. After being deauthenticated (and therefore disassociated), clients cannot use roaming mechanisms to move to another AP. The client will choose to associate to the original BSSID, to the 2.4 Ghz BSSID from the same AP, or to another AP.
The clients must discover the new channel (or a new BSSID) by themselves, either listening to beacons, sending probes, or using information from the neighbor report if 802.11k is implemented. Clients must then do authentication, association, PSK or 802.1X authentication.
This will break voice calls and realtime audio/video conferencing. Buffered multimedia streaming may or may not be impacted, asynchronous traffic such as web and email may not notice any interruption.
Since the fallback channel can be defined, there is some room to ensure that the destination channel is U-NII-1 in a contingency channel plan.
Returning back to the original channel
The switchback to the original channel seems to be totally silent. Client stations won’t receive ACKs to their frames, beacons will be missed, and the clients will eventually move to another channel or BSSID. In addition, CAC will be performed by the AP on the original DFS channel.
This means service disruption for all kind of traffic. The only upside is that clients will keep their association, so that after learning AP information via beacons, probes or neighbor reports, the client can roam to another BSSID. If 802.11r is enabled, roaming may be fast and almost seamless.
Impact on channel plans
Deployments with low AP and user density, in domains where U-NII-1 and U-NII-3 channels are available, should exclude DFS channels from the channel plan.
High density deployments with potential high co-channel interference should carefully evaluate the requirements and choose a trade-off between service availability and airtime:
sticking to non-DFS channels will prevent occasional service disruption caused by radar events, but due to CCI the airtime % use will be high and the service will be severely degraded permanently.
including DFS channels in the channel plan will minimize CCI, at the price of the occasional disruption caused by radar evens (real or false positives).
Whichever you choose, it is important to state the issue clearly to the organization management. Users should be informed of the service level they can expect from the wi-fi network.
Mitigation
Extreme Networks in their support documentation recommends to monitor the occurrences of DFS events, and exclude the frequently offending channels from the custom channel plan on an AP by AP base. There is no dynamic RRM for DFS issues in 3900 APs, only an initial auto channel setup called ACS (automatic channel selection).
Other techniques that I have found helpful are:
Enable 802.11k to help clients finding their next AP. This is important even if there are no radar events, as clients cannot do active discovery on DFS channels.
Plan 2.4 Ghz wisely. Clients will probably associate to the same AP on 2.4, if available.
Design good secondary coverage. If there are 2 APs in a lecture hall, configure one AP on an U-NII-1 channel and another on a DFS channel.
Long term solution
Unfortunately, the only permanent solution to this issue is replacing 3900 and 3800 APs with more modern models that implement Channel Switch Announcement correctly. This may be expensive, given the high number of 3900s installed and the longevity of the product. Management should be informed of the issue and involved in the assessment of its impact.
Final considerations
DFS events in the wild are difficult to capture and analyze. Vendor datasheets and documentation may not go in such details. You should always validate the DFS implementation of your APs, you could be in for a surprise. Buy a Wifimetrix and go testing, or have a WLAN professional do it for you.
Floor plans in Ekahau Pro designs are strictly 2D. Tri-dimensional features can be added using wall height, AP height and ceiling height in a building artifact, which is basically a stack of floor plans scaled and aligned vertically. In a building, the hole in floor is a powerful tool to render complex features such as balconies, staggered floors, stairwells, courtyards and shafts. Despite all this 3D features, floor plans are strictly horizontal, and cannot represent inclined surfaces, slopes or stadium tiers.
I had to design wi-fi for a small lecture hall recently, and thought I could have some fun stretching Ekahau 3D concepts to the limit and learning something new.
The lecture hall was built in the 1920s with a steep auditorium design that enabled attendees to hear and see the podium without any audio/video technology, even from the farthest seat. It has 13 rows of seats on a stepped floor, each step 40cm high.
Auditorium, front, back and side section view
ground floor
first floor view
To simulate the stepped floor I planned a building with 14 identical floor plans (one for each seat row), each floor with 40 cm ceiling height. Using holes in floor I then planned to cut out every floor leaving only the step area, and placing a 40 cm high wall on the step rise.
Lesson learned 1: the minimum ceiling height in Ekahau Pro is 1m. I had to simplify the design by grouping the steps and reducing the building from 14 to 7 floors.
Using the hole in floor tool I cut out the floors, placed a custom 1m high wall to simulate the step rise, and added areas and attenuation areas on the active surfaces on each level.
ground floor
steps 1-2
steps 3-4
steps 5-6
steps 7-8-9
steps 10-11-12
The first 6 stacked floors, each with area, hole in floor, step wall and attenuation areas
I placed a simulated AP in floor 1 at 4m height and displayed the signal strength at every seat row. Lesson learned 2: even if the ceiling is 1m, the software allows placing an AP higher, regardless of floors above.
At first, the predictive design did not display the RF signal on the all the floors. Lesson learned 3: enable Signal prediction: all floors on the Options button. Please also note that the default visualization height is 1m from the floor, this can be customized with Ctrl+Options.
Playing with the AP position and height allows to explore the different attenuation effects in 3D space. It is an approximation to the real shape of the hall, and of the RF attenuation effects, as good as the Ekahau software goes.
Here is an example of predictive signal strength in 5Ghz, where the attenuation from areas, floors and walls is clearly visible. Besides signal strength, all the usual visualizations are possible; my other favorites are Capacity and Health.
AP at 4m
The signal strength prediction on the stepped seat rows
This technique is fun, but unless there are very specific requirements in designated areas, this kind of auditorium design is an overkill in real life. During surveys, this design would force switching floor plan every few meters. Viewing survey data would also be unpractical.
A much simpler solution was suggested by Ferney Muñoz during the 17a Sesión de Tes@s en Wi-Fi when I gave a small presentation: if the APs are placed on the ceiling at the same height and the auditorium seat rows are stepped, just reduce the AP height accordingly from front to back. In other words, simulate an inclined floor using the APs instead of the floors.
Conclusion:
The floor plan sandwich technique is fun and provides detailed simulation of complex building artifacts…
…but it’s probably terrible for surveys.
The software limits the minimum ceiling height to 1m.
Simulated APs can be placed at any height, regardless of upper floors.
RF signal prediction is done at 1m height from the floor, customizable.
Enable signal prediction to all floors in order to see how an AP impacts the whole 3D model.
Legal note: Ekahau and Ekahau Pro are registered trademarks of Ekahau OY.
I am doing a project for a library warehouse with compact sliding shelves. It’s a large area in the basement with rows of metal bookshelves.
insert librarian here
caution!
librarian inside
Every shelf is fitted on rails and has a crank that allows sliding an entire row left and right. Once the chosen shelf has been opened wide, a librarian can access the books inside and start working.
It’s basically a warehouse with moving aisles.
During the initial engagement phonecall I asked what the needs for wi-fi were, what type and how many devices had to connect, physical access procedures, security issues. I like to study the floorplans beforehand and prepare an Ekahau project with just the correct scale set, and nothing else.
A sector of the library warehouse.
I usually call the first site visit “the photoshoot”: while the contact person guides me around the premises, I ask questions and take pictures. Later I will return, taking measures, usually alone, but the photoshoot is focused on getting the most from my guide’s time.
I use the “stream of consciousness” photographic method: starting from the main entrance, I document the journey in the building every 3-4 m, at every turn, stair, door, floor sign or fire escape plan. I like to have pictures of the ceiling, cabling, MDF, outstanding furniture. Later at the office it will be easy to review the picture stream and compare it to my memory of the journey. Months after the visit, when you ask yourself “What was the ceiling like in room 1505?” this method allows me to find the right information among hundreds of pictures.
My contact person walked me around the library warehouse and kindly answered my questions. The whole warehouse is located underground and is quite big. It has just one landline phone, no cellphone coverage, some weak wifi signal leaking from the floor above. I helped my guide express her use cases in this way:
A a librarian, I need to use the laptop to access the database while I am doing work inside the compactus aisles.
As a supervisor, I need a simple communication channel for colleagues in case of need while in the warehouse.
This translates in basic connectivity for web access from laptops, and chat apps on mobile devices.
The next step at the office was to develop the predictive project, defining areas, requirements, walls and attenuation areas. I created a custom attenuation object for the compact racks, 2.5m high and 27dB/m. My reasoning is that the sturdy metal shelves and the material inside will totally block any wifi signal.
This project will focus on coverage for low density areas, with simple 2×2:2 ac Extreme Networks 3915 APs .
The predictive signal from an AP placed on the ceiling 1m above the compact shelving does not travel very far down the aisles. In the picture below a simulated AP is placed at 3.5m height, the shelves are 2.5m high. Please note that the default predictive signal in Ekahau is simulated at 1m above the floor.
Predictive signal strength on 5Ghz at 14 dBm (18dBm EIRP)
Predictive design in Ekahau simulates the signal attenuation caused by free space path loss and wall/obstacle attenuation. It does not factor in reflection and other complex RF propagation effects. But here the environment is very complex: on the ceiling there are metal conduits, cabling trays, concrete rafters, low-ceiling areas and shelves of different size and model.
To validate the predictive design with actual measurements on site, let’s do an AP on a stick survey! I gathered my survey gear and headed to the library. After placing the APOS in a specific position I walked in a sliding aisle every 4 racks measuring the signal with the Sidekick. This time I was on my own, al the doors were open and the area was freely accessible and very quiet. I really enjoyed the time spent most productively there.
Placing an AP in the same position as the simulated AP above gave very encouraging results. The signal is pretty good inside the shelves, even far away from the AP.
5Ghz at 12 dBm (16 dBm EIRP), as measured
Adding a small offset to the measured data still shows decent coverage in awkward locations. The AP could be moved to a more central position, or the EIRP increased slightly.
5Ghz at 12 dBm (16 dBm EIRP), viewed as generic laptop -3dB
Even the notorious mobile device offset (around -10 dB) shows a workable coverage. Clients in the gray areas may choose 2.4 Ghz, the EIRP could be increased, or there would be just low RSSI and basic data rates.
5Ghz at 12 dBm (16 dBm EIRP), viewed as mobile device -10dB
The difference in the results from predictive design and from APOS can be explained perhaps as an excessive attenuation value in the predictive model. My personal view however is that multipath has an important role in that complex environment.
Based on the results on the field, I designed the whole library warehouse using a reasonable number of APs. The project is underway and I will share the validation results once it’s installed.
I built my own wi-fi stand with 7€ worth of hardware store supplies. It fits nicely to my 30€ nondescript tripod for my AP on a stick surveys.
It’s basically a 1000mmx25mmx1mm steel strip, bent in a rectangle and bolted fast to an iron plate. It is slightly wider than the usual 23.8mm (15/16″) ceiling rail.
In horizontal mount position, heavier APs like this Extreme Networks 3935 are a bit wobbly, but stable nonetheless.
The vertical position is done rotating the mount and attaching the AP sideways.
I can even fit an outdoor AP 3965 with its heavy mounting plate.
I simply hang the outdoor AP 3965 using the mounting plate and the pole mount straps. I insert the stand above for safety reasons, and use work gloves for handling the AP because of the pole-mount sharp edges.
This wifi stand may not be stylish or refined, but it’s very practical!
The Sybex CWAP 2011 study guide contains a gem regarding how different BSSs interact:
[with the exception of transmitter and receiver,] Any other client or AP stations within hearing range on the same channel will reset their NAV, even if they are nont members of the BSS.
Chapter 3 review questions, q.10, answer p.120
It is the first time I find it clearly stated that STAs contending through HCF or EDCA will abide to any information they can decode from received frames, regardless if they are from the same BSS or not.
This makes sense, because:
APs know the AID of the members of it’s BSS, but client STA don’t;
any STA (AP or client) does physical carrier sense SD when it decodes a preamble, and it is likely to also decode the header which contains a length field which is the time it will take to transmit the frame (in microsecs);
Therefore it’s logical to use a NAV if it can decode it.
Perhaps this should be put in the CWNA study guide explicitly.
Today I took the CWSP exam and passed it with 90%. It’s exactly one year after I passed CWNA and the satisfaction and sense of accomplishment is great. The original plan was to study during winter and spring 2020 in order to take the exam in April. Then the COVID19 pandemic hit and changed all our priorities.
The current exam was CWSP-206, which has an official study guide from Certitrek (authored by Badman, Bartz, Carpenter, Hill, Morgan) and an almost updated (CWSP-205) study guide from Sybex (authored by Coleman, Westcott, Harkins).
A great guide by David Coleman, David Westcott and Bryan Harkins
It’s good to study both books: the Sybex is a high quality reference guide to understand our work, and the Certitrek a more exam-oriented tool with great content, but somewhat poor editorial depth (e.g. no chapter/section navigation, no index).
How to pass an exam and have fun with Kali Linux
I did not practice or setup a lab specifically for this exam, as most of my day to day work already touched most of the topics. Keeping up to date with blogs, Twitter and webinars was very useful, see my Twitter profile @MonorailHandles for my followed profiles which are almost all wi-fi related.
The CWNP practice tests were very useful to gauge my level of readiness and study the finishing touch. As with CWNA, the pass threshold is 70% and having scored 90% in the exam means I overstudied and delayed: chalk it up to an astonishing year with a pandemic, african locusts swooped over Milano by high altitude winds, and an earthquake near home.
Pearson Vue’s online proctored exam worked smoothly, I sat in an empty room at my office and the absolutely bare space may have helped the experience. It’s a good alternative to the physical exam center, in both convenience and comfort.
Now to the next thing: the original plan was CWDP, but my interests and professional curiosity drive me towards CWAP. Let’s see in the next weeks.
Early Aygust I was surveying one of the university buildings in Milano with my colleague. A heatwave was underway with outside temperatures of 35°C and in-building 30°C. We moved by bike, carrying survey kit and spare APs in my bike bags.
The building itself is interesting: a former cinema belonging to the nearby church, later rented by our university, the cinema transformed into a 200-seat lecture hall, the above floors offices. The view on the nearby XVI century church and art-nouveau buildings is wonderful.
We spent the morning surveying the building. Most of the time was used picking keys from a huge keyring and opening offices – then closing them again. After a couple of hours the tethered survey device was really hot and I didn’t want to stuff it back in the bag, even if it was turned off. So I found a creative solution:
Using all 5 Ghz channels available in your regulatory domain is not a choice, it’s a matter of fact. Here’s my experience.
I did a validation survey at one of our remote sites. The survey data showed severe co-channel interference almost everywhere. The site lies in open countryside and has no detectable neighboring APs: all of the APs are our own and they all transmit in the same 4 non-DFS channels as shown in the reading taken at location A on site:
