5GHz not visible after 380.66 update on RT-AC3200

[Nikolay Kiselev]

Test with channel 36 to determine if it's a compatibility issue between your devices.

RMerlin,

I had the same issues with Samsung Galaxy S8 (it could not see 5Ghz network). After I set my 5Ghz network "control channel" to 36 then Samsung Galaxy S8 found the 5Ghz network.

The following parameters of "control channel" make 5Ghz network visible for Samsung Galaxy S8: 36, 40, 44, 48.

If I set "control channel" to 52, 56, 60, 64, 100, 104, 108, 112, 116, 132, 136 or 140 then my cell phone doesn't "see" 5Ghz network.

Many thanks!

 

[RMerlin]

RMerlin,

I had the same issues with Samsung Galaxy S8 (it could not see 5Ghz network). After I set my 5Ghz network "control channel" to 36 then Samsung Galaxy S8 found the 5Ghz network.

The following parameters of "control channel" make 5Ghz network visible for Samsung Galaxy S8: 36, 40, 44, 48.

If I set "control channel" to 52, 56, 60, 64, 100, 104, 108, 112, 116, 132, 136 or 140 then my cell phone doesn't "see" 5Ghz network.

Many thanks!

Then it means your phone does not support DFS channels.

 

[shaft120]

Ok - So not sure what eventually became of this and the thread here: https://www.snbforums.com/threads/wifi-issues-on-380-66-and-380-66_2-on-rt-ac88u.39257/#post-326574 and here: https://www.snbforums.com/threads/r...ess-issue-resolved-see-post-8-24.39305/page-2
However, I am on version 380.69 and have all of the same listed problems described in the threads:

• 5Ghz network wasn't always visible
• Devices no always able to connect to Wifi although can be seen
• IoT devices not being seen properly
• Data rates being unusable <500k etc

I am also using my old RT-AC66U on merlin as an AP as an earlier poster, so not sure if this is adding to issues. I have activated the smart-connect and use an additional AP upstairs. The 3200 is downstream from a Virgin Modem on a different sub-net and the wired connections all work fine.
I see there is a 384.3 release now, so will try that and follow the hard reset steps in 'post 8' for the last link, but was there ever an agreed issue recognised here?