Disable AP status light in Extreme CloudIQ

This is so stupid and still not so easy to find out: to turn off the LED of an AP in Extreme Networks CloudIQ, go to Manage > Devices, select your APs, click on Utilities > Tools > Locate your device.

You will be presented a dialog to switch-off the light or start a blinking pattern.

This feature is meant for troubleshooting and device location, when you are on-site and don’t know where a specific AP is. Just configure a blinking pattern on XcloudIQ and see which AP blinks.

If you place APs in hotel rooms, student dorms or home bedrooms, you MUST turn the LED light off. Otherwise, people will cover it with chewing gum, stickers, tampons or anything at hand.


The safety of Wi-Fi in Europe

In 2015 the European Commission has published a scientific opinion on the health impact of electromagnetic field exposure, via it’s Scientific Committee on Health, Environmental and Emerging Risks (SCHEER).

The Opinion was first published in 2009 and updated in 2015 in the final official version. It is an analysis of existing research on the health impact of a broad range of EMF, including those typical in WLAN technologies.

In case you are wondering: under the conditions dictated by the European regulatory domain, wi-fi is safe.

An easy to read fact-sheet (1 page pdf) is available, in a format and language accessible to non-specialists. An easy to navigate summary of the Opinion is also published, good for high level browsing and quick drill-downs. The full document is 218 pages and is freely downloadable from the EU Commission site.

This documents can be referenced in the WLAN policy documents of your organization. Users concerned about the health aspects of the coroporate WLAN should be directed to the policy, or to the original documents.


Towards wi-fi 6E in Italy

The approval of 6Ghz spectrum for wi-fi 6E use in Europe is governed by the European Commission decision 2021/1067/UE from 17 June 2021.

This Decision harmonises the conditions for the availability and efficient use of the 5945-6425 MHz frequency band for wireless access systems including radio local area networks (WAS/RLANs).

Commission Implementing Decision (EU) 2021/1067

By 1 December 2021 Euroean member states had to make available the 5.945-6.426 Ghz frequency band. The deadline expired and as of now, only the Netherlands have harmonized it (23 December 2021) and Ireland (11/1/2022).

Frequency band allocation in Italy is regulated by the Piano Nazionale di Ripartizione delle Frequenze (PNRF) from the Ministry of Economic Development. The latest PNRF is from 2018 and does not allow 6Ghz for WAS/RLAN.

An open consultatin on a new PNRF draft (which includes the 5.945-6.426 Ghz frequency band use) is underway with a deadline at 31 January 2022. The timetable after the consultation closes is not known.

It is possible that an updated PNRF will be published in the first months of 2022, opening up the 6Ghz frequency band in Italy and making wi-fi 6E possible in Italy.

I will follow the developments closely.


Notes from GARR Workshop 2021

Interesting wi-fi talks at GARR Workshop 2021 last November.

Paul Dekkers from SURFnet speaks about Eduroam, openroaming (Hotspot2.0 and Passpoint), CAT and the geteduroam app. Geteduroam has many advantages over CAT and will eventually supersede it. Slides and video.

GARR’s Pasquale Mandato presents eduroam usage data during the 2020/2021 pandemic in Italy, GARR’s self-service tools for Eduroam technical contacts in Italy, highlights and pitfalls of geteduroam, and the little known companion app. Slides and video of the talk (Italian).

Daniele Albrizio from University of Trieste analyzes the security of eduroam and the importance of using CAT for device onboarding. Communicating with the eduroam user base is crucial, and tough choices must be made, such as phasing-out support for older, obsolete client devices. Slides and video (Italian).



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.


Validating DFS in Extreme AP410C

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.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.


Validating DFS in Extreme AP 3900 series

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.


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.


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:

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) or DFS 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 code
A 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.


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.


Fun with Ekahau 3D design

Heritage building at University of Milan, Italy

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

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.

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.

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.


  • 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.

The sliding requirements

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.

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.

Coverage areas, walls, attenuation areas, simulated APs

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.


Build your own wi-fi stand

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!