Recently, I needed to create a lab router using IPFire. While configuring the wireless access point, I ran into an issue where it briefly worked and then failed. Essentially, the access point’s SSID appeared, then stopped before any of my devices could connect to it.

It was extremely frustrating, but thankfully, switching to 2.4 GHz immediately fixed the problem. I searched the logs and found several entries relating to something called “DFS.”

Eventually, curiosity got the better of me, and I dragged my spare mini PC back onto the desk. I just couldn’t ignore the failure and needed to understand what went wrong.

As it turned out, the answer had more to do with military, aviation, and civilian radar than I’d expected from what should have been a boring Wi-Fi setup.

I went back to the Wi-Fi failure I’d worked around

The channel was listed, but my adapter just couldn’t use it as an access point

My Zotac mini PC’s career as an LLM host didn’t pan out so well, but its Ubuntu Server installation made a perfect wireless bench test. I used its onboard Intel Wireless-AC 3165 with hostapd, the software responsible for running an access point on operating systems like Linux and BSD.

Setting hostapd to channel 52 immediately reproduced the same failure. That specific channel requires Dynamic Frequency Selection (DFS), a mechanism that generously allows Wi-Fi to share radio frequency spectrum with radar systems. It first checks to see if there are active radar transmissions within Wi-Fi range, then changes the channels if they are found.

These two distinct log entries identified the issue:

DFS-CAC-START freq=5260 chan=52 ... cac_time=60s 
DFS start_dfs_cac() failed, -1

This check is called the CAC, or Channel Availability Check. Previously, I’d blamed the CAC’s delay for the failures, but the timestamps clearly showed the service hadn’t lost patience. Rather, it just couldn’t start in the first place.

I tried these two controls to try and make sense of it:

1. 5 GHz channel 36, which doesn’t require DFS, also failed. Its NO-IR (No Initiate Radiation) restrictions strictly prohibited initiating any transmissions such as access point beacons.
2. 2.4 GHz channel 6 worked, producing AP-ENABLED and a network my phone could finally see.

That narrowed down the problem to the broader 5 GHz AP restrictions rather than 2.4 GHz. Linux’s Intel driver documentation also clearly identifies a 5 GHz AP limitation, which for me ended up being the final piece of the puzzle.

Finally, it had clicked that joining a network and hosting one requires vastly different capabilities. Connecting to a DFS channel doesn’t mean that an adapter can perform an AP’s radar checks in the first place. Instead, it might just refuse to host an access point on those affected channels at all.

Wi-Fi shares this spectrum with systems that are higher priority

Once I understood that my Intel wireless adapter came with built-in limitations, I wanted to know what a more advanced and capable router might do differently. DFS does let Wi-Fi use certain frequencies, but only on the condition that it checks for radar and stands well clear when it detects it.

In the US, the DFS channel groups are designated 52–64 and 100–144, although not every router is capable of using all of them. These bands overlap with radar infrastructure, including weather monitoring, aviation, and sometimes military.

That big white sphere you often see at an airport? That’s a Doppler Weather Radar, one prime example of the type of infrastructure your router might be sharing its RF space with.

So, why allow a Wi-Fi router to meddle with these frequencies at all? The big attraction is the extra room. More channels mean more alternatives to crowded non-DFS spectrum, including space for wider Wi-Fi channels.

The US requirements explain why that extra room comes with such strict obligations:

And no, that 10-second window isn’t permission to quickly fire off some packets. Normal traffic must be limited to 200 ms after detection, with limited control transmissions allowed to enable the network to move off the channel.

I used virtual radios to watch DFS in action

The simulation showed the sequence my physical adapter refused to complete

Living in the middle of nowhere wasn’t helping my efforts to find a legitimate source of radar. The nearest airport is over 160 miles away, and my Intel wireless adapter refused to even check anyway.

Luckily, Linux had another option. mac80211_hwsim can create virtual Wi-Fi radios for testing real networking software without transmitting a single packet over the air. With this tool, I could run hostapd against simulated hardware and watch its behavior.

I used this command to create two virtual radios:

sudo modprobe mac80211_hwsim radios=2

I assigned wlan0 to the access point. The second radio remained unused at this point as it wasn’t a client connectivity test. My configuration retained my country’s setting (AU) and used channel 52 at 20 MHz:

interface=wlan0
driver=nl80211
ssid=DFS-Simulation
country_code=AU
ieee80211d=1
ieee80211h=1
hw_mode=a
channel=52
ieee80211n=1
wmm_enabled=1

I started it with timestamped logging:

sudo hostapd -t hostapd-dfs-simulation.conf 2>&1 | tee dfs-simulation-cac.log

This time, the CAC wait actually happened. The timestamps clearly showed 60.002 seconds between DFS-CAC-START and successful completion. Only after this one-minute check did AP-ENABLED finally appear.

With hostadp still running, I opened another SSH session and injected a radar event through the simulator’s test interface. Hostapd’s own DFS tests use this exact mechanism. Only on my machine, the virtual AP belonged to radio phy1:

printf '1n' | sudo tee  
/sys/kernel/debug/ieee80211/phy1/hwsim/dfs_simulate_radar

The next response is actually what I would’ve observed if my physical AP actually tried, and I had an airport radar next door:

• The software reported radar on channel 52.
• It switched to non-DFS channel 153.
• Channel 52 became immediately unavailable for use.

When I checked with iw phy phy1 channels, I confirmed that channel 52 was indeed in an unavailable state.

It took watching a simulated version with software to wait, switch, and exclude the DFS channel to make the process more tangible and understandable. All without having to visit the airport with my Wi-Fi router.

I can see why router manufacturers might skip DFS channels entirely

When there’s competing infrastructure, more spectrum doesn’t equal a better connection

At this stage, there were three obvious reasons to avoid DFS channels altogether:

1. They require suitable hardware and software.
2. Starting a network can involve some waiting.
3. Radar detection will force an otherwise working network to change channels.

How much control you get does vary. Some routers expose DFS options, including whether automatic channel selection can even use them. ASUS, for example, documents that exact setting. Others can leave you without any choices whatsoever.

My ZTE U30 Pro mobile router is a great example of this. It allows me to select 2.4 GHz or 5 GHz, but doesn’t expose any channel selection. That level of restriction was frustrating enough for me to go through my tech cupboards looking for a device that could allow it. Unfortunately, I never found one.

There are still plenty of good arguments for enabling these channels on supported equipment. If the non-DFS channels are oversaturated, additional spectrum can be a big help. I’d just want to establish first that the benefit of doing so won’t interrupt everyday use.

Therefore, before relying on DFS, I’d ask these three questions:

1. Does my model support DFS, and how does its automatic selection work in practice?
2. Can all my devices find and join that network?
3. If unexpected channel changes do occur due to radar detection, can I view these explicitly in the router logs?

I’d check the trade-off before chasing an empty channel

Researching this definitely changed how I’d interpret the channels my router chooses

My final scan showed the ZTE router and my Starlink Wi-Fi advertising 80 MHz networks in non-DFS channel blocks. That snapshot didn’t tell me why they’d chosen them, or whether they avoided DFS by default.

It did leave me with a much better understanding of my original failure with the IPFire router. A channel appearing in an adapter’s list doesn’t actually guarantee it can host a network there.

I’d consider DFS on suitable equipment only if congestion gave me a valid reason to try it. But if I did, I’d go in expecting the checks and the router changing channels straight back to congested bands anyway.

But for now, living in the middle of nowhere means my gear isn’t competing with radar, but it also means the non-DFS channels aren’t congested enough to warrant trying.