
Pulled from the 5Gstore customer archives, this one is worth revisiting because it comes up again every time a new firmware build lands. A customer running a Peplink B One 5G upgraded to firmware 8.6.0 build 6450 and immediately noticed that his 5 GHz Wi-Fi had fallen apart. The fix took about thirty seconds, and it had nothing to do with the firmware version.
The Symptoms
Here is the report in the customer’s own words, lightly condensed:
I had the setting for 5 GHz Wi-Fi set to Automatic. I observed that signal strength was very poor just one bedroom over in my house. Between one bar and no bar. Speed on a 100 megabit WAN was only 6 megabits. I benchmarked on a Samsung tablet and phone. The phone occasionally saw the SSID but then it would disappear. I did a search for best 5G bands. The article suggested using channel 36. So I changed my 5 GHz SSID to channel 36, 80 MHz width. Bingo. Signal strength went to 5 bars and 100 megabits throughput. It matched the performance of my 2.4 GHz SSID.
One bedroom away. Not across the yard, not through a brick wall, one interior wall. That is the tell.
What Was Actually Happening
The customer assumed this might be a firmware bug introduced in 8.6.0. It almost certainly was not. What changed during the upgrade is that the radio came back up, re-ran its automatic channel selection, and landed somewhere different than it had been sitting before. Auto channel selection is a snapshot decision. The AP scans, picks the quietest channel at that instant, and commits.
Three things make that snapshot decision go badly on 5 GHz.
DFS channels behave differently. Channels 52 through 144 fall into the Dynamic Frequency Selection range, shared with weather and military radar. An access point operating there has to listen for radar before it transmits, and it beacons more conservatively. Client devices frequently scan those channels passively, meaning the phone waits to hear a beacon rather than actively probing for it. That is exactly why the customer’s phone would see the SSID, then lose it, then see it again. A network that flickers in and out of the available list is a classic DFS signature, not a weak radio.
Transmit power is not equal across the band. Regulatory limits differ between the U-NII sub-bands, and vendors set conservative defaults on the DFS ranges. Two channels that look identical in the dropdown can deliver noticeably different real world coverage through walls.
Higher frequencies lose more through building materials. Channel 165 sits at 5.825 GHz. Channel 36 sits at 5.18 GHz. That difference is small on paper and meaningful once drywall, studs, ductwork, and a mirror or two get involved.
Channel 36 sits at the bottom of U-NII-1, is non-DFS, is actively scanned by essentially every client, and propagates better than anything above it. When the customer locked to it, the problem disappeared.
How to Set It on Your Peplink
Log into the router’s web admin and go to the AP tab, then AP Settings. The relevant controls are in the screenshot below.
Work through these fields:
- Channel Width (5 GHz): set to 80 MHz. This gives you the throughput headroom without pushing into 160 MHz, which is far more sensitive to interference and less consistently supported by clients.
- Channel (5 GHz): change from Auto to 36 (5.18 GHz). Note that an 80 MHz channel anchored at 36 consumes channels 36, 40, 44, and 48. That is the entire U-NII-1 block, which is fine in a home but worth knowing if you are deploying multiple APs.
- Auto Channel Update: once you set a fixed channel this schedule no longer applies to that radio. Leave the 2.4 GHz schedule alone if you are still running Auto there.
- Output Power: Max with Boost enabled, as shown. Be aware of the warning directly beneath it. Boost can exceed local regulatory limits, so use judgment based on where you are and what else is nearby.
- Click Apply Changes at the bottom of the page.
Reconnect your clients after the change. Some devices cling to a stale channel entry and need Wi-Fi toggled off and back on before they follow the AP.
If you want to be more rigorous about the channel choice, Peplink’s AP status page and InControl 2 both expose a nearby networks view that shows which channels your neighbors are occupying. If channel 36 is crowded in your building, try 149 next. It is the bottom of U-NII-3, also non-DFS, and usually the second best option in a dense environment.
Is Auto Ever the Right Setting?
Yes. Auto is a reasonable default for a mobile deployment that changes location constantly, a fleet vehicle, or any site where nobody is going to log in and tune anything. It is also fine in genuinely noisy environments where a fixed channel would eventually collide with something new.
Where Auto tends to disappoint is a fixed installation with a known RF environment. In a house, an office, or a permanent remote site, picking the channel yourself is almost always better than letting the radio guess once and never revisit the decision. Two minutes of manual configuration beat months of “the Wi-Fi is weird in the back bedroom.”
The other reason to fix the channel is troubleshooting sanity. When the channel can change on its own overnight, intermittent complaints become nearly impossible to reproduce.
Firmware Notes
For the record, this behavior is not specific to 8.6.0. The same pattern shows up on 8.5.x and earlier, and on plenty of other vendors’ access points. What a firmware upgrade does is force a radio restart, which triggers a fresh channel selection. That is why so many people first notice the problem right after an update and reasonably conclude the update caused it.
Current Peplink firmware and release notes are available from Peplink’s download page, and the Peplink community forum is a good place to check whether a specific build has known radio issues before you deploy it across a fleet.
This Is Not Just a Peplink Thing
Automatic channel selection works the same way across the industry, so the same tuning logic applies whether you are running Peplink, Cradlepoint, Teltonika, Semtech, Inseego, Digi, or Katalyst hardware. Every one of these vendors ships an auto channel option, and every one of them will occasionally park your radio somewhere that looks clean to the AP and terrible to your laptop two rooms away. If you are seeing unexplained 5 GHz coverage problems on any of them, check the operating channel first.
5Gstore Take
We see this one constantly, and it almost always gets misfiled as a hardware problem or a firmware regression. Before you RMA a router, downgrade firmware, or start shopping for a mesh system, log in and look at what channel your 5 GHz radio actually selected. If it is anywhere in the DFS range and your coverage is poor, lock it to 36 or 149 and retest. The odds are good you are done.
The broader lesson is that “Auto” settings are optimized for the average deployment, and almost nobody runs the average deployment. A few minutes spent understanding your own RF environment pays for itself.
If you are not sure which channel makes sense for your site, or you want help planning coverage across multiple access points, reach out to the 5Gstore team. We have been sizing and tuning these deployments for a long time and we are happy to talk through yours.
FAQ
Does firmware 8.6.0 have a 5 GHz Wi-Fi bug?
No evidence of one here. The upgrade restarts the radio, which re-runs automatic channel selection and can land the AP on a worse channel than it was using before. The same thing happens on 8.5.x and on other vendors’ equipment.
Why is channel 36 recommended?
It is non-DFS, so there is no radar avoidance behavior and clients scan it actively rather than passively. It sits at the low end of the 5 GHz range at 5.18 GHz, so it penetrates walls slightly better than the upper channels. It is also allowed at reasonable transmit power in the United States.
What if channel 36 is congested where I am?
Try 149. It is the lowest channel in U-NII-3, also non-DFS, and generally the best fallback. Check the nearby networks view in your AP status page or InControl 2 to see what your neighbors are using before you decide.
Should I use 80 MHz or 160 MHz channel width?
80 MHz is the safer choice for most deployments. It delivers strong throughput while remaining resilient to interference. 160 MHz doubles your exposure to interference and forces you into DFS territory in most channel plans.
Why did my phone keep seeing the SSID and then losing it?
That is typical of DFS channels. Client devices often scan those channels passively, waiting to hear a beacon instead of probing for the network. Combined with weak signal, the SSID appears and vanishes from the list. Moving to a non-DFS channel resolves it.
Will fixing the channel hurt anything?
Only if your RF environment changes significantly and something new starts transmitting on your channel. In a fixed installation that is rare, and if throughput ever degrades you can re-survey and pick a different channel or switch back to Auto.
Does this apply to 2.4 GHz too?
The DFS piece does not, since 2.4 GHz has no DFS channels. But the general principle holds. On 2.4 GHz stick to channels 1, 6, or 11, since those are the only non-overlapping options at 20 MHz width.

