Tuning a UniFi UDR7 for a 3-Floor Townhouse: Channel Planning, Band Steering, and 75% Fewer Drops

The symptoms were annoying but not dramatic. WiFi drops a few times a day. Speedtests in the basement that looked nothing like the 2.5 Gbps connection upstairs. One iPad that performed noticeably worse than an iPhone sitting two feet from it. Samsung TVs that occasionally just couldn’t connect.

I had a tri-band WiFi 7 Dream Router 7 sitting on the middle floor of a three-story townhouse with roughly 40 wireless clients — phones, tablets, TVs, streaming sticks, Nest, Ring, Wyze cameras, smart plugs, a Keurig, a Samsung refrigerator, and a pile of ESP32-based IoT sensors. I’d already done the basics: IoT and Guest VLANs, zone-based firewall rules. The infrastructure side was solid. The wireless side clearly wasn’t.

I logged a baseline. 152 client disconnect events in 24 hours. Basement far corner speedtest: 47 Mbps.

Time to actually dig in.

Getting Into the Data

UniFi gives you three useful data layers if you’re willing to go beyond the GUI: SSH directly into the device, the MongoDB database the controller runs locally, and the local Network API. I used all three.

SSH into the UDR7:

ssh <user>@<UDR7-IP>

From there, mca-dump gives you a raw JSON dump of the device’s current radio state — channel assignments, TX power, BSSID list, association table. iw dev and iwconfig fill in the gaps with per-interface details. These are read-only views of what the controller has actually pushed to the radios, which is useful when you suspect the GUI isn’t telling the whole story.

MongoDB queries:

UniFi runs MongoDB locally on port 27117, and all the controller data lives in the ace database. You can query it directly:

mongo --quiet --port 27117 ace --eval "db.event.find({key: 'EVT_WU_Disconnected'}, {_id:0, datetime:1, ap:1, client:1, channel:1}).sort({datetime:-1}).limit(20).pretty()"

This pulls raw disconnect events with timestamps, AP MAC, client MAC, and channel. Grouping by channel immediately showed the shape of the problem:

mongo --quiet --port 27117 ace --eval "
db.event.aggregate([
  { \$match: { key: 'EVT_WU_Disconnected', datetime: { \$gt: new Date(Date.now() - 86400000) } } },
  { \$group: { _id: '\$channel', count: { \$sum: 1 } } },
  { \$sort: { count: -1 } }
]).pretty()"

The output:

Channel 112. Sixty-one disconnects from a single 5 GHz DFS channel in one day. That was the first thing I needed to chase.

Local Network API:

For per-client stats — retry rates, signal strength, band distribution — I pulled from the controller’s local API using an API key generated in the Network app under Integrations:

curl -sk -H "X-API-KEY: <key>" \
  https://<UDR7-IP>/proxy/network/api/s/default/stat/sta | \
  jq '.data[] | {hostname, signal, channel, tx_retries, tx_packets, radio}'

That tx_retries / tx_packets ratio is the clearest signal of link quality. Anything above 0.15 is struggling. I had clients pushing 0.40+.

# Band distribution
curl -sk -H "X-API-KEY: <key>" \
  https://<UDR7-IP>/proxy/network/api/s/default/stat/sta | \
  jq '[.data[] | .radio] | group_by(.) | map({band: .[0], count: length})'

That returned something I did not expect:

[
  {"band": "ng", "count": 27},
  {"band": "na", "count": 1}
]

Twenty-seven clients on 2.4 GHz. One on 5 GHz. The 6 GHz radio had zero clients. I had a WiFi 7 router and almost every device in the house had camped on the worst band.

I also pulled the rogue AP scan:

curl -sk -H "X-API-KEY: <key>" \
  https://<UDR7-IP>/proxy/network/api/s/default/stat/rogueap | \
  jq '.data[] | select(.essid == "<MainSSID>") | {bssid, essid, channel, rssi, oui}'

That one needed some attention.

Root Causes

The baseline picture: a single UDR7 trying to cover three floors, no coordination with a rogue second AP, and auto settings that had optimized into a corner. Here’s what the environment looked like before any changes.

flowchart TD
    Internet([Internet]) --> UDR7

    subgraph Middle Floor
        UDR7["UDR7\n(middle floor — only managed AP)"]
    end

    subgraph Basement / Lower Floor
        OldAP["Old Nighthawk\n(same SSID, no roaming coordination)\nch 9 / ch 157"]
    end

    UDR7 -- wired --> OldAP

    subgraph Clients["Client Cloud (40 devices)"]
        C1["Phones / Tablets"]
        C2["Smart TVs"]
        C3["IoT Devices"]
    end

    UDR7 -. "2.4 GHz ch 11 / 5 GHz ch 112\n(DFS — radar dropouts)" .-> Clients
    OldAP -. "2.4 GHz ch 9\n(overlaps UDR7)\n5 GHz ch 157\n(overlaps UDR7 80 MHz block)" .-> Clients

    Clients -- "ping-pong: no 802.11r/v/k\nbetween APs" --> UDR7
    Clients -- "arbitrary association\nno graceful handoff" --> OldAP

1. DFS Channel 112 — The Invisible Dropout Machine

UniFi’s auto channel selection landed on channel 112, which sits in the DFS (Dynamic Frequency Sharing) band. DFS channels have to vacate when radar is detected — mandatory by FCC regulation. When a hit occurs, the radio goes dark for 30–60 seconds while it finds a new channel. From the client’s perspective, that looks like an AP disappearing.

Sixty-one disconnects in 24 hours, all on channel 112. Radar events don’t always get surface-level alerts in the GUI, but the MongoDB disconnect log doesn’t lie.

2. 2.4 GHz TX Power at Max — The Sticky Client Factory

The router was running 2.4 GHz at 23 dBm (High power). This creates an asymmetric link: the router is shouting loud enough for clients to hear it from far away, but those same clients — phones, cameras, IoT devices with small antennas — can’t shout back with enough power for the router to hear them cleanly.

The result is exactly what I saw: high retry rates, sticky clients refusing to roam (because they can still “hear” the AP and don’t know they have a weak uplink), and silent packet loss. The clients thought they had a good connection. The router knew otherwise.

3. 6 GHz at 320 MHz Width — Theater

320 MHz channels are the theoretical maximum for WiFi 7 on 6 GHz. In a lab benchmark, great. In a real house, you’re trading range for bandwidth you can’t use. 6 GHz doesn’t penetrate walls and floors as well as 5 GHz — a 320 MHz channel on 6 GHz is invisible past one room. My zero-client count on that radio confirmed it. I was broadcasting a band that nothing in the house could actually reach reliably.

4. The Old Nighthawk — The Biggest Offender

This one I didn’t expect to be as bad as it was.

The rogue AP scan returned BSSIDs with a Netgear OUI at -6 to -8 dBm — a device sitting on my own network, broadcasting my own SSID. I cross-referenced it with the wired client list in the controller: a Netgear Nighthawk connected to a switch port, visible in the wired client table.

Someone — me, during a coverage experiment months ago — had plugged an old Nighthawk into the network, set it to repeat the same SSID, and never removed it. It was broadcasting on 2.4 GHz channel 9 (overlapping the UDR7’s channel 11) and 5 GHz channel 157 (overlapping the UDR7’s 80 MHz block from channel 149).

Same SSID, no roaming coordination. 802.11r/v/k (fast BSS transition, BSS transition management, neighbor reports) only work when APs are under the same controller using the same infrastructure. The Nighthawk knew nothing about the UDR7. So when a client got close to the Nighthawk, it might associate there. When it moved away, neither AP had any mechanism to hand it off gracefully. The client would just ping-pong between whatever signal it happened to see — and each reassociation looked like a disconnect event in the logs.

This was almost certainly the single biggest driver of that 152/day number.

5. Band Stickiness — A Compounding Effect

The 27-on-2.4 / 1-on-5 distribution wasn’t random. It was a consequence of everything above. Clients originally connected to 2.4 GHz because the 5 GHz radio was dropping (DFS events) and because the Nighthawk was broadcasting strongly on 2.4. Once clients associate with a band, they don’t voluntarily move without a push — and with no minimum RSSI configured and no BSS transition management nudging them, they just stayed. The 5 GHz radio was sitting at 1% channel utilization.

6. WPA3 Transition Mode and the Samsung TV

I had WPA3 transition mode enabled, which allows mixed WPA2/WPA3 associations on the same SSID. In theory this is the best of both worlds. In practice, one of the Samsung TVs couldn’t negotiate it at all — it just wouldn’t show the network. Disabling WPA3 on the main SSID required dropping 6 GHz from that SSID’s band list because the FCC mandates WPA3 on 6 GHz. That’s a real compatibility constraint worth knowing about: older smart TVs and appliances will hit this wall.

7. No Minimum RSSI

With no minimum RSSI threshold configured, there was nothing to push sticky clients off the AP when their signal degraded. This is less critical with a single AP — aggressive min RSSI on one AP with no other coverage just kicks clients into the void — but it becomes important once a second AP is in the picture.

The Fixes, In Order

1. Pinned 5 GHz to channel 149 (non-DFS, high band)

Immediate. No more radar events, no more 30–60 second blackouts on 5 GHz. Channel 149 is in the UNII-3 block (5745–5825 MHz) — no DFS requirement, high throughput.

2. Reduced 6 GHz channel width from 320 → 160 MHz

160 MHz still delivers excellent throughput for clients that can use 6 GHz, with meaningfully better range than 320 MHz. If a device is close enough to use 6 GHz at all, it’ll be close enough to get full speed at 160 MHz.

3. Capped 2.4 GHz TX power to 17 dBm (Medium)

This creates a more symmetrical link. Clients that can only hear the router at a distance will stop associating — which is actually what you want, because they couldn’t maintain a clean uplink anyway. Let them stay on 5 GHz where the power budget is better matched.

4. Unplugged the Nighthawk

Confirmed offline via wired client status in the controller — the entry disappeared. This was the single highest-impact change. The channel interference on 2.4 GHz and the uncoordinated SSID conflict both went away simultaneously.

5. Force-migrated clients to 5 GHz

I temporarily disabled 2.4 GHz on the main SSID for about 5–10 minutes. Every client was forced to reassociate, and most landed on 5 GHz because that’s what was available. When I re-enabled 2.4 GHz, the band distribution had shifted from 27/1 to something much more even. Clients that belonged on 5 GHz were now there.

6. Disabled WPA3 transition mode, dropped 6 GHz from the main SSID

Main SSID is now pure WPA2-PSK with PMF set to optional. 6 GHz is reserved for a separate SSID for devices that can actually use it. The Samsung TV can connect again.

7. Set DNS on IoT and Guest VLANs

Both VLANs had no DNS configured — they were falling back to ISP DNS, which added latency and occasionally failed for smart home devices that expected fast resolution. Set both to 1.1.1.1 primary and 9.9.9.9 secondary.

8. Disabled auto-firmware-upgrade

Automatic firmware updates can reboot the AP mid-day with no warning. I prefer to stage updates during a maintenance window.

9. Bumped 2.4 GHz minimum data rate from 1 Mbps to 6 Mbps

This drops legacy 802.11b rates from the beacon. 802.11b devices are effectively extinct on a modern home network, and keeping 1 Mbps as the floor wastes airtime on management frames broadcast at the lowest rate. At 6 Mbps minimum, management traffic moves faster, freeing capacity for actual data.

10. Enabled network-wide DNS-based ad and tracker blocking

Less about WiFi performance, more about cleaning up chatty IoT traffic hammering DNS resolvers constantly. Fewer wasted lookups, less noise in the air.

11. Added a U7 Pro Wall as a second AP with wired backhaul

Wall-mounted, 2.5 Gbps wired uplink to the Cisco switch. Placed on the lower floor to cover the basement. Wall-mount APs radiate forward — they’re designed to project signal into a room from a wall, not broadcast in every direction from a ceiling. Placement relative to the coverage target matters more with a wall AP than with a ceiling unit.

12. Coordinated channels between the two APs

This is where I ran into the first mistake (more on that below). Final configuration:

The non-overlap here is not just about channel numbers — it’s about the actual spectrum blocks those channels occupy at your configured width. Here’s the picture:

graph LR
    subgraph 2_4GHz["2.4 GHz Band"]
        direction LR
        CH1["Ch 1\n2412 MHz"]
        CH6["Ch 6\n2437 MHz\n(U7 Pro Wall)"]
        CH11["Ch 11\n2462 MHz\n(UDR7)"]
    end

    subgraph 5GHz["5 GHz Band (selected blocks)"]
        direction LR
        BLK36["Ch 36 block\n5180–5240 MHz\n(U7 Pro Wall)\n80 MHz wide"]
        GAP[" "]
        BLK149["Ch 149 block\n5745–5825 MHz\n(UDR7)\n80 MHz wide"]
    end

    style CH6 fill:#4a9eff,color:#fff
    style CH11 fill:#ff7043,color:#fff
    style BLK36 fill:#4a9eff,color:#fff
    style BLK149 fill:#ff7043,color:#fff
    style GAP fill:none,stroke:none

Channels 6 and 11 on 2.4 GHz are non-overlapping (22 MHz wide channels, 25 MHz spacing). Channels 36 and 149 on 5 GHz are fully separated blocks — no shared spectrum at 80 MHz width.

13. Matched TX power on the new AP

17 dBm on 2.4 GHz to match the UDR7. Consistent power budgets across both APs means clients roam based on signal quality, not because one AP is dramatically louder than the other.

14. Set minimum RSSI to -80 dBm on 5 GHz (then adjusted)

With two APs providing coverage, minimum RSSI is now useful — there’s somewhere to go. More on the tuning below.

After all changes, the network topology looks like this:

flowchart TD
    Internet([Internet]) --> UDR7

    subgraph Upper ["Upper / Middle Floor"]
        UDR7["UDR7\n2.4 GHz ch 11 | 5 GHz ch 149\n17 dBm TX | no DFS"]
    end

    subgraph Lower ["Lower Floor / Basement"]
        U7Wall["U7 Pro Wall\n2.4 GHz ch 6 | 5 GHz ch 36\n17 dBm TX | wired backhaul"]
    end

    UDR7 -- "2.5 Gbps wired\n(Cisco switch)" --> U7Wall

    subgraph VLANs["VLANs (both APs)"]
        Trusted["Trusted SSID\nWPA2 | 2.4+5 GHz"]
        IoT["IoT SSID\nWPA2 | isolated"]
        Guest["Guest SSID\nWPA2 | isolated"]
    end

    UDR7 --> VLANs
    U7Wall --> VLANs

    subgraph Clients
        Upper_C["Phones / Tablets\n(upper floors)"]
        Lower_C["TVs / IoT\n(lower floor / basement)"]
    end

    UDR7 -. "802.11r/v/k\ncoordinated roaming" .-> Upper_C
    U7Wall -. "802.11r/v/k\ncoordinated roaming" .-> Lower_C

What Didn’t Work as Planned

Channel 161 for the new AP’s 5 GHz — interference I didn’t catch immediately

My first instinct was to put the U7 Pro Wall on channel 161 to complement the UDR7 on channel 149. I didn’t catch immediately that channels 149 and 161 are in the same 80 MHz block: the 5745–5825 MHz range. At 80 MHz width, both channels use overlapping spectrum. Clients near either AP would see contention.

The fix was moving the U7 Pro Wall to channel 36 (UNII-1 band, 5180–5240 MHz). No overlap, fully separated blocks.

Min RSSI at -75 dBm kicked the Samsung TV

I started with -75 dBm as the minimum RSSI threshold on 5 GHz. The Samsung TV was sitting at -78 dBm and couldn’t finish its association before getting kicked. Relaxed to -80 dBm, which helped — but the TV was right at the edge and experiencing flaps. During the reconfig period when clients were actively moving between bands and APs, I disabled min RSSI entirely to let things settle, then re-enabled at -80 once the network stabilized.

Open attack surface that’s still there

Two port forwards are still exposed to the internet: Plex and a Minecraft server. Neither is behind Cloudflare Tunnel. This is a known item — flagged it, haven’t migrated it yet. The Minecraft server in particular needs a dedicated tunnel configuration since it’s TCP game traffic, not HTTP. It’s on the list.

Results

Four-plus days post-changes, the numbers are stable:

Daily disconnect trend over the 7-day measurement window:

xychart-beta
    title "Daily WiFi Disconnect Count"
    x-axis ["Day 1\n(baseline)", "Day 2", "Day 3\n(changes applied)", "Day 4", "Day 5", "Day 6", "Day 7"]
    y-axis "Disconnect Events" 0 --> 250
    bar [150, 80, 215, 34, 46, 30, 44]

Day 3 shows the spike during the change window itself — clients being force-migrated between bands and APs generates reassociation events that look like disconnects. From Day 4 onward the count stabilized in the 30–46 range.

Band distribution shift:

xychart-beta
    title "Client Band Distribution — Before vs After"
    x-axis ["2.4 GHz", "5 GHz", "6 GHz"]
    y-axis "Connected Clients" 0 --> 30
    bar [27, 1, 0]
    bar [21, 13, 0]

Before: 27 clients jammed on 2.4 GHz, one on 5 GHz, nothing on 6 GHz. After: 5 GHz went from 1 client to 13. The 2.4 GHz count dropped as higher-capability devices moved to 5 GHz where they belong. The 6 GHz count stayed at zero on the main SSID — it’s now reserved for a dedicated 6 GHz SSID that WiFi 6E/7 devices can use.

Basement speed improvement:

The 47 → 249 Mbps jump at the basement far corner is driven almost entirely by the U7 Pro Wall placement. That’s a 5.3x improvement from putting the right hardware in the right spot — not from any configuration change on the UDR7 itself. Coverage hardware placement matters more than most settings.

The speedtest improvement is sustained, not a one-time dip.

One limitation worth naming: 2.4 GHz channel utilization is holding at 40–55%. That’s not my network — it’s neighbor APs. An apartment building or dense neighborhood creates co-channel interference you can’t fix from your own controller. 2.4 GHz is a shared medium and always will be. The best mitigation is minimizing how much of your traffic stays on it, which is why the band steering work matters.

Lessons Learned

Default “auto” channel selection will land you on DFS. UniFi’s algorithm optimizes for a clean channel at that moment in time — it has no way to know whether there’s a radar source nearby that will trigger hits at 2 AM. Manually pin to non-DFS channels and you never have to think about it again.

Wider isn’t faster when range is the constraint. 320 MHz on 6 GHz looks impressive in a spec sheet. In a real house with real walls, range collapses before you can use the throughput. Match the channel width to the actual coverage cell, not the theoretical maximum.

Wall-mounted APs aren’t ceiling APs. They radiate forward into the room, not omnidirectionally. If you’re mounting a wall AP expecting it to cover rooms behind the wall, it won’t. Placement needs to match the radiation pattern.

An unmanaged “second AP” on the same SSID is always worse than no second AP. It sounds like you’re adding coverage, but without 802.11r/v/k coordination, what you’re actually adding is a competing source of the same SSID that clients will arbitrarily associate with and never leave. If you want a second AP, wire it and put it under the same controller. If you can’t do that, a different SSID is better than the same one.

Min RSSI is dangerous with one AP, useful with two. With a single AP, min RSSI just kicks clients into an area with no coverage. With two APs providing overlapping coverage, it becomes the mechanism that drives clients to roam. Don’t enable it until you have somewhere for clients to go.

The WPA3 / 6 GHz mandate is a real compatibility wall. If you have devices from 2019 or earlier, especially smart TVs or appliances, WPA3 transition mode will break some of them and you won’t know why until you dig into the logs. Plan your SSID strategy around it: main SSID on WPA2, separate SSID on 6 GHz with WPA3 for devices that can handle it.

The UDR7 is a genuinely capable device. But capable hardware running default settings in a complex RF environment doesn’t automatically deliver good performance. It needs to be tuned.

Tagged: UniFi · networking · homelab · WiFi 7