SSID broadcast on 5G band

[Slartibartfast]

Since about 2014 official Asus firmware has broken the SSID broadcast on the 5G band (on the RT-A66U and apparently all other devices too). Do Merlin builds fix this issue? I tried to search for a answer here but couldn't come up with a query which returned anything relevant.

Thanks.

 

[RMerlin]

Can you be more specific? Because tens of thousands of users are using an Asus router with the 5 GHz band broadcasting the SSID without any problem.

 

[JDB]

I'm assuming he refers to this https://vip.asus.com/forum/view.asp...00&board_id=11&model=RT-AC66U&page=1&count=25


Sent from my iPhone using Tapatalk

 

[RMerlin]

I'm assuming he refers to this https://vip.asus.com/forum/view.asp...00&board_id=11&model=RT-AC66U&page=1&count=25


Sent from my iPhone using Tapatalk

A bunch of different cases there, many of them unrelated. Pretty sure the RT-AC87U reporters are suffering from a failed Quantenna chip. Those with channel 0 have either a dead radio, or corrupted nvram and need to do a factory default reset and manually set it to a channel supported by their country. Wouldn't surprise me that in fact some of these are running their router in the wrong region, so their clients are failing to detect their router as it uses a non-supported channel.

In fact, if you look at the reports here on SNBForums, almost every single case reported so far turned out to be either corrupted nvram, or a hardware failure.

So no, it's almost certainly not a firmware issue, or the problem would be far, far more widespread.

 

[Slartibartfast]

Yes, that is one of the discussions of the problem, but there are others.

I'm assuming he refers to this https://vip.asus.com/forum/view.asp...00&board_id=11&model=RT-AC66U&page=1&count=25


Sent from my iPhone using Tapatalk

 

[Slartibartfast]

With respect, despite your dismissal it most definitely IS a firmware problem since the issue can be resolved by reverting to official firmware 3.0.0.4.380_3831 or earlier. On my RT-AC66U installing any later Asus firmware results in no clients of any type being able to see the 5G SSID. Reverting to 3.0.0.4.380_3831 or earlier restores 5G SSID broadcast. It is NOT a hardware failure else it wouldn't work on earlier firmware. BTW, I did a factory reset and nvram clear as part of my troubleshooting, and the only thing which restored 5G SSID broadcast was firmware reversion.

Since it seemed switching back and forth between stock and Merlin firmware was trivial I decided to just go ahead and try it. I am happy to report that Merlin 380.65_0 works fine and the 5G SSID is visible to all clients. Just to be sure I reflashed the latest stock firmware and the 5G SSID disappeared again. Even more proof that later stock firmware builds bork the 5G SSID broadcast.

Is there some way to mark this thread as resolved?

A bunch of different cases there, many of them unrelated. Pretty sure the RT-AC87U reporters are suffering from a failed Quantenna chip. Those with channel 0 have either a dead radio, or corrupted nvram and need to do a factory default reset and manually set it to a channel supported by their country. Wouldn't surprise me that in fact some of these are running their router in the wrong region, so their clients are failing to detect their router as it uses a non-supported channel.

In fact, if you look at the reports here on SNBForums, almost every single case reported so far turned out to be either corrupted nvram, or a hardware failure.

So no, it's almost certainly not a firmware issue, or the problem would be far, far more widespread.

 

[L&LD]

With respect, despite your dismissal it most definitely IS a firmware problem since the issue can be resolved by reverting to official firmware 3.0.0.4.380_3831 or earlier. On my RT-AC66U installing any later Asus firmware results in no clients of any type being able to see the 5G SSID. Reverting to 3.0.0.4.380_3831 or earlier restores 5G SSID broadcast. It is NOT a hardware failure else it wouldn't work on earlier firmware. BTW, I did a factory reset and nvram clear as part of my troubleshooting, and the only thing which restored 5G SSID broadcast was firmware reversion.

Since it seemed switching back and forth between stock and Merlin firmware was trivial I decided to just go ahead and try it. I am happy to report that Merlin 380.65_0 works fine and the 5G SSID is visible to all clients. Just to be sure I reflashed the latest stock firmware and the 5G SSID disappeared again. Even more proof that later stock firmware builds bork the 5G SSID broadcast.

Is there some way to mark this thread as resolved?

If all you're doing is flashing between firmware versions (stock or otherwise), then you're not really testing anything properly. Particularly when you have issues like you are showing.

A full and proper reset to factory defaults is needed to eliminate any interference from previously written firmware due to changes to variables and other structures in the NVRAM.

The following is what I suggest you should try to fully test a new version of firmware properly. Some say it's not needed if their router works as expected without doing so, but that doesn't mean there are no issues present. Just that their setup doesn't show those issues (for now).

https://www.snbforums.com/threads/n...l-and-manual-configuration.27115/#post-205573

https://www.snbforums.com/threads/rt-ac66u-slow-wan-to-lan.12973/page-3#post-269410

https://www.snbforums.com/threads/faq-nvram-and-factory-default-reset.22822/


After doing the above and staying on a firmware version that is stable for your network with all the options and features enabled as you wish, you may want to use the following utility by john9526 to have a quick and proper way to flash your settings to a newly loaded firmware (after a full and proper reset to factory defaults). In the worst case scenario; the utility will show you your settings in a text file (human readable) where you can copy and paste quickly too.

https://www.snbforums.com/threads/user-nvram-save-restore-utility-r24a.19521/

 

[RMerlin]

Since about 2014 official Asus firmware has broken the SSID broadcast on the 5G band

it most definitely IS a firmware problem since the issue can be resolved by reverting to official firmware 3.0.0.4.380_3831 or earlier.

Your initial claim was that this was broken since 2014. Now you say it was broken since last autumn. That's quite a big difference there...

 

[Slartibartfast]

Yep, sorry, not sure where I got the idea that firmware was from 2014. I should have just posted the release number in my original question, but the exact date it started acting up was not really important. I just wanted to know if the Merlin builds did the same thing as the last three official builds have. The answer I found by trying it is "no". Thanks for you great work on this project.

Your initial claim was that this was broken since 2014. Now you say it was broken since last autumn. That's quite a big difference there...

 

[Slartibartfast]

Just because I said I decided to just try Merlin and see because flashing back and forth was easy doesn't mean I didn't do a full factory reset in between (I did). My configuration is easy because I use my RT-AC66U in access point mode (I run pfSense in a vmWare VM on an always-on PC as my actual firewall). The Asus just functions as an AP and 5-port switch. After a factory reset I just need to set the IP address and configure my WiFi bands the way I want them. After a factory reset it takes me about 2 minutes to set up my Asus again.

If all you're doing is flashing between firmware versions (stock or otherwise), then you're not really testing anything properly. Particularly when you have issues like you are showing.

A full and proper reset to factory defaults is needed to eliminate any interference from previously written firmware due to changes to variables and other structures in the NVRAM.

...

 

[RMerlin]

The answer I found by trying it is "no".

That would probably be because 380.65 is based on 380_3xxx, aside from a few portions from 380_4180. If the issue was introduced by Asus in 4180, then it will also appear in my firmware in the next version, as the wireless-related code is closed source, and therefore 100% identical to Asus's.

The first thing I would check however, since those are things Asus recently changed:

1) Disable DFS channels (in case you live in an area where radars are using that band, forcing you off it)
2) Disable Airtime Fairness (quite a few clients seem to be having problems with it)

I also still recommend keeping MU-MIMO disabled, as it's pretty much completely broken on Broadcom's chips. That doesn't apply to the RT-AC66U however, as it has no MU-MIMO support.

 

[eddiez]

On .66 here, but never had any issue with any previous firmware...and I have used them all...

Aren't you mixing up the invisible channels enigma when 5Ghz is reset to automatic after flashing a new firmware? This is just not an enigma any more...just set it manual to a channel below 100; some client chipsets don't look any further

 

[L&LD]

Just because I said I decided to just try Merlin and see because flashing back and forth was easy doesn't mean I didn't do a full factory reset in between (I did). My configuration is easy because I use my RT-AC66U in access point mode (I run pfSense in a vmWare VM on an always-on PC as my actual firewall). The Asus just functions as an AP and 5-port switch. After a factory reset I just need to set the IP address and configure my WiFi bands the way I want them. After a factory reset it takes me about 2 minutes to set up my Asus again.

Like I said; it was just a suggestion.

But what I find interesting is that you are not running the RT-AC66U as a router. It is in a much more complex setup than that. (Which may explain why other's do not see your issue).

 

[Slartibartfast]

"If the issue was introduced by Asus in 4180, then it will also appear in my firmware in the next version"

I wondered about that. Hopefully not.

"1) Disable DFS channels (in case you live in an area where radars are using that band, forcing you off it)
2) Disable Airtime Fairness (quite a few clients seem to be having problems with it)"

Where would I find these settings?

"That doesn't apply to the RT-AC66U however, as it has no MU-MIMO support."

I just yesterday set up an RT-AC68U in another application, is this something I should be concerned about? I flashed it with your latest build for that device. If so, how do I turn MU-MIMO off? I think the AC68U is pretty much just an upgraded AC66U, so it probably doesn't have the MU-MIMO feature either.

Thanks.

That would probably be because 380.65 is based on 380_3xxx, aside from a few portions from 380_4180. If the issue was introduced by Asus in 4180, then it will also appear in my firmware in the next version, as the wireless-related code is closed source, and therefore 100% identical to Asus's.

The first thing I would check however, since those are things Asus recently changed:

1) Disable DFS channels (in case you live in an area where radars are using that band, forcing you off it)
2) Disable Airtime Fairness (quite a few clients seem to be having problems with it)

I also still recommend keeping MU-MIMO disabled, as it's pretty much completely broken on Broadcom's chips. That doesn't apply to the RT-AC66U however, as it has no MU-MIMO support.

 

[Slartibartfast]

"It is in a much more complex setup than that"

Yes the configuration is complex, but the AC66U's role in that setup is simple, simpler in fact than doing all the work itself.

But what I find interesting is that you are not running the RT-AC66U as a router. It is in a much more complex setup than that. (Which may explain why other's do not see your issue).

 

[RMerlin]

1) Disable DFS channels (in case you live in an area where radars are using that band, forcing you off it)
2) Disable Airtime Fairness (quite a few clients seem to be having problems with it)"

Set 5 GHz channel to 36, and disable Airtime Fairness under Wireless -> Professional.

 

[L&LD]

"It is in a much more complex setup than that"

Yes the configuration is complex, but the AC66U's role in that setup is simple, simpler in fact than doing all the work itself.

Did RMerlin's suggestion fix your issue? (Hope it did).

The AC66U's role may be simple, but it is still interacting and being interacted with a complex setup that others don't normally have.

If the above suggestion didn't fix your issue, then is there anyway you can do a step by step reset and then slowly add features one at a time and see where it begins to break?

 

[Slartibartfast]

Hard to tell if it would have fixed the problem since the latest version of Merlin isn't built from a stock firmware version which displays this problem. As I have flashed the router with Merlin it no longer exhibits this issue, but it probably will again when Merlin starts building from leter stock firmware versions.

Did RMerlin's suggestion fix your issue? (Hope it did).

The AC66U's role may be simple, but it is still interacting and being interacted with a complex setup that others don't normally have.

If the above suggestion didn't fix your issue, then is there anyway you can do a step by step reset and then slowly add features one at a time and see where it begins to break?