DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes

To diagnose and resolve DFS radar events on Cisco Meraki, HPE Aruba, or Ruckus WiFi networks operating under the IEEE 802.11h standard, analyze your controller logs for radar detections. Once detected, the access point must vacate the 5GHz channel within 10 seconds and remain off it for 30 minutes.

What does a DFS radar event look like on your 5GHz network?

Dynamic Frequency Selection (DFS) lets WiFi share parts of the 5GHz band with radar. IEEE 802.11h defines the mechanism. Regulators set the timings: the FCC under 47 CFR Part 15.407 in the US, and ETSI EN 301 893 across Europe. In ETSI regions, channels 52 to 64 and 100 to 140 are DFS channels. FCC rules add channel 144.

When an access point (AP) detects radar, the sequence is fixed:

1. Detection. The radio matches a pulse pattern on its operating channel to a radar signature.
2. Channel switch announcement (CSA). The AP adds a CSA element to its beacons, telling clients the new channel and the countdown to the move.
3. Channel move. The radio must stop transmitting on that channel within 10 seconds.
4. Non-occupancy period. The channel is off-limits for at least 30 minutes.
5. Channel availability check (CAC). Before a DFS channel goes into service, the radio listens for at least 60 seconds. In ETSI regions, channels 120, 124 and 128 (5600-5650 MHz) are shared with weather radar, and the check there lasts 10 minutes.

What guests experience depends on their devices. Clients that honour the CSA follow the AP with a short pause. Clients that ignore it lose the connection, rescan and reassociate, often on 2.4GHz or a neighbouring AP. If the AP moves to a DFS channel that has not passed its check, the 5GHz radio can stay silent for a minute or longer.

The pattern to look for:

• Every client on one AP, or on a group of neighbouring APs, drops at the same moment.
• The AP returns on a different channel, often a non-DFS channel between 36 and 48.
• The change falls outside your scheduled channel optimisation window.
• The same APs repeat the pattern, sometimes at similar times of day.
• 2.4GHz load jumps while 5GHz clients disappear.

What usually causes DFS channel changes?

Genuine radar

Weather radars in the 5600-5650 MHz range are a common genuine source in Europe. In the US, Terminal Doppler Weather Radar (TDWR) at major airports uses the same range. Line of sight matters more than distance. Outdoor APs, upper floors and glazed facades detect radar that ground-floor APs never see.

Proximity alone predicts little. Many airport surveillance and maritime navigation radars operate in other bands, well outside 5GHz. A venue beside a port may never log a single radar event. Your event log is the evidence, not the map.

False positives

A DFS false positive is a radar detection with no radar present. The radio reads a burst of energy as a radar pulse pattern. Typical triggers include:

• pulsed non-WiFi interference from wireless video links or faulty equipment;
• strong transmissions from a nearby AP or point-to-point link on an adjacent channel;
• radio or firmware defects, which vendors correct in software releases.

The tell is isolation. One AP logs repeated events on varied channels while neighbours with the same view of the sky log none.

Wide channels raise exposure to both genuine and false detections. An 80 MHz channel spans four 20 MHz sub-channels, and a detection on any of them moves the whole channel.

Non-radar changes that look the same

Channel planners move radios for interference and load. Meraki Auto RF, Aruba ARM and AirMatch, and Ruckus ChannelFly and BackgroundScanning all change channels without radar. AP reboots and power changes also drop clients. These faults need different fixes, so confirm the reason before you exclude anything.

How do you work out whether radar caused the outage?

Work through this checklist in order:

1. Pin the complaint. Get the time to the minute and the room, floor or zone.
2. Pull channel-change events for the APs serving that area, one hour either side.
3. Read the logged reason. A radar or DFS reason confirms the cause. An interference, noise or optimisation reason rules it out.
4. Note the channel. Events clustered on 120, 124 and 128 point to weather radar.
5. Count the affected APs. Several neighbours together suggest genuine radar. One AP alone suggests a false positive.
6. Look for a weekly pattern. Regular repeats suggest a radar with a fixed schedule or sweep.
7. Check channel width. Events that appear only on 80 or 160 MHz channels make width part of the problem.
8. Read the firmware release notes for DFS detection fixes on your AP model.

If you run Purple Guest WiFi, login volumes by venue give you a cross-check. A sharp dip at one site that lines up with a radar event confirms guest impact.

How do you fix DFS events on Meraki, Aruba and Ruckus?

Vendor	Where radar events appear	Channel planner	Where you restrict channels
Cisco Meraki	Wireless event log filtered for DFS events; RF spectrum page per AP	Auto RF	RF profile channel list, applied to affected APs
HPE Aruba	ARM history on the controller or Instant cluster; AirMatch events in AOS 8 and Aruba Central	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	Allowed channel list in the radio profile for an AP group
Ruckus	SmartZone events and alarms for radar detection	ChannelFly or BackgroundScanning	Radio settings for a dedicated zone or AP group

Cisco Meraki

Meraki records radar detection in the event log as DFS events, naming the AP and channel. Filter by event type and the complaint window. The RF spectrum page for each AP shows utilisation and interference, which separates radar from congestion. To stop recurrence, remove the problem channels from Auto RF in an RF profile. Apply that profile only to the affected APs. Meraki's own DFS documentation covers the exact steps.

HPE Aruba

ARM history lists each channel change with its reason, and radar detection appears as a distinct reason. AirMatch builds the channel plan centrally, but a radar hit forces the AP to move straight away. An unscheduled mid-afternoon change on a DFS channel is therefore a strong clue. Restrict channels in the radio profile for an AP group containing only the affected APs. If guests are sent back to a login page after reconnecting, that is a separate fault: see the HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist.

Ruckus

SmartZone raises an event when an AP detects radar, naming the AP and channel. Check events and alarms for the window, then compare them with ChannelFly or BackgroundScanning activity. A Ruckus DFS channel change with no radar event behind it is a planner decision, not DFS. Remove problem channels in the radio settings for a dedicated zone or AP group.

On all three platforms, change the affected APs only. A site-wide exclusion costs capacity on APs that never saw radar.

Should you disable DFS channels near an airport, port or weather radar?

Not by default. Excluding every DFS channel in an ETSI region leaves four 20 MHz channels: 36, 40, 44 and 48. FCC rules leave nine, adding 149 to 165. In a high-density venue, four channels force APs to share airtime and slow every client. Let the logs decide.

What your logs show	Likely cause	Recommendation	20 MHz channels left (ETSI / FCC)
Events on several neighbouring APs, clustered on 120-128	Weather radar	Exclude 120, 124 and 128 on affected APs	16 / 22
Events on most DFS channels across many APs, daily	Strong nearby radar	Exclude DFS on affected APs only; keep it elsewhere	4 / 9 on affected APs
Repeated events on one AP, varied channels	False positive	Update firmware, test or replace the radio, keep DFS	19 / 25
Events only on 80 or 160 MHz channels	Width exposure	Drop to 40 or 20 MHz, keep DFS	19 / 25
Channel changes but no radar entries	Planner or interference	Fix interference and power, keep DFS	19 / 25

Worked scenario: a hotel near a regional airport

A 180-room hotel in an ETSI region sat 3 km from an airfield with a weather radar. Guests on west-facing upper floors reported drops most afternoons. The event log showed 63 radar events in one week on 11 of 46 APs, all on channels 120 to 128. The team moved those 11 APs to a profile excluding the weather channels and set 40 MHz width. Over the next four weeks the hotel logged zero radar events. WiFi complaints at the front desk fell from 14 to two a week. The other 35 APs kept every DFS channel. For more on hotel deployments, see Hotels.

Worked scenario: a retail chain with one noisy AP

A 120-store retail chain saw one store log 30 radar events in a fortnight on channels 52, 100 and 116. Neighbouring APs in the same store logged none, which pointed to a false positive. The release notes for the AP model listed a DFS detection fix, so the team upgraded firmware. Events continued, and the AP was replaced under warranty. Radar events at the store dropped to zero, and shoppers stopped losing connections at the tills area. The estate kept all 19 channels. See Retail for multi-site guest access.

Worked scenario: council offices beside a port

A council IT team planned to disable DFS at offices next to a commercial port. Thirty days of logs showed no radar events at all. The channel changes came from the planner reacting to a neighbouring tenant's network. The team kept DFS, lowered transmit power and fixed the channel plan. Weekly drop reports fell from nine to one.

How do you stop DFS events disrupting guests again?

• Use 20 or 40 MHz channels in dense venues. Narrower channels reduce exposure and add reuse.
• Exclude weather channels surgically where events cluster on 120 to 128, on the affected APs only.
• Keep firmware current and read DFS fixes in each release note.
• Review DFS events monthly, and alert on any AP logging more than a handful a week.
• Plan for 6GHz. The 6GHz band carries no DFS requirement, so WiFi 6E and WiFi 7 clients avoid radar moves entirely.
• Separate RF from guest access. Purple runs as a hardware-agnostic cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Your controller owns the channel plan, and Purple owns the guest login. Purple served 440 million logins across 80,000+ live venues in 2024 (Purple data).

Frequently asked questions

Does Purple Guest WiFi work on our existing Meraki, Aruba or Ruckus access points?

Yes. Purple Guest WiFi is a hardware-agnostic cloud overlay that runs on Cisco Meraki, HPE Aruba and Ruckus, alongside Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep your access points, controllers and RF configuration. Purple adds the guest login, conscious-choice opt-ins and first-party data on top. No rip and replace is required, and your DFS settings stay under your control.

Will Purple change our DFS or channel settings?

No. Purple does not set radio channels, channel width or transmit power. Those stay in Meraki Auto RF, Aruba ARM or AirMatch, and Ruckus ChannelFly or BackgroundScanning. Purple handles guest authentication and data capture above the radio layer. That separation lets you fix a DFS problem in your vendor dashboard without touching the guest login experience, and change login settings without touching RF.

Is it compliant to disable DFS channels?

Yes. ETSI EN 301 893 and FCC Part 15.407 require radar detection on any DFS channel you use. Neither requires you to use DFS channels. Excluding them is always compliant. What you must never do is operate on a DFS channel with detection disabled. The real cost of exclusion is capacity: in ETSI regions, removing every DFS channel leaves four 20 MHz channels instead of 19.

Do we need new access points to avoid DFS problems?

Not usually. Most DFS problems are fixed with configuration: excluding weather channels on affected APs, narrowing channel width or updating firmware. Replacement makes sense when one radio keeps producing false positives after a firmware update, or when you add 6GHz capacity. The 6GHz band has no DFS requirement, so WiFi 6E and WiFi 7 access points remove radar moves for clients that support them.

Will excluding DFS channels hurt guest WiFi at a busy venue?

Yes, if you exclude them site-wide. In an ETSI region, four 20 MHz channels cannot separate dozens of APs in a stadium, conference centre or large hotel. APs end up sharing airtime and throughput falls for every guest. Exclude channels only on the APs that log radar, and keep DFS everywhere else. That approach contains the problem without giving up capacity.

Do DFS rules differ between the UK, Europe and the US?

Yes. The UK and EU follow ETSI EN 301 893, which applies DFS to channels 52 to 64 and 100 to 140. It also requires a 10-minute availability check on weather channels 120, 124 and 128. The US follows FCC Part 15.407, which adds channel 144 and leaves nine non-DFS channels. Both require at least 30 minutes of non-occupancy after a detection.

Can an MSP diagnose DFS events across a mixed-vendor estate?

Yes, but radar events live in each vendor's own tooling: the Meraki event log, Aruba ARM history or AirMatch events, and SmartZone events and alarms. An MSP should standardise the checklist rather than the tool, and record time, channel, AP count and reason for every incident. Purple gives you one platform for guest access across all those vendors, while RF diagnosis stays in each controller.