RT-AC86U: unable to connect to 5 GHz

[Ohia]

I've had a new RT-AC86U for a few months, running Merlin 384.9 (previously had an AC68U). Today I decided to disable SmartConnect, since all my devices were connecting to 2.4 GHz only. So I explicitly created a 5 GHz network.... that none of my devices can connect to! My MacBook claims "the Wi-Fi network requires a WPA2 password". My iPhone claims the password is incorrect (it's not, I double-checked). I've rebooted and power cycled the router. I've tried a different SSID, but still no luck.
Is my router's 5 GHz radio broken? I can't really think of another explanation at this point. My settings are pretty standard, but if there's anything you'd recommend I try I would love to hear from you, thanks!

 

[OzarkEdge]

I've had a new RT-AC86U for a few months, running Merlin 384.9 (previously had an AC68U). Today I decided to disable SmartConnect, since all my devices were connecting to 2.4 GHz only. So I explicitly created a 5 GHz network.... that none of my devices can connect to! My MacBook claims "the Wi-Fi network requires a WPA2 password". My iPhone claims the password is incorrect (it's not, I double-checked). I've rebooted and power cycled the router. I've tried a different SSID, but still no luck.
Is my router's 5 GHz radio broken? I can't really think of another explanation at this point. My settings are pretty standard, but if there's anything you'd recommend I try I would love to hear from you, thanks!

Did you reset the router after installing the firmware?

OE

 

[Ohia]

Did you reset the router after installing the firmware?

Yes, reset to defaults and then pain-stakingly adjusted the settings by hand...

 

[OzarkEdge]

Yes, reset to defaults and then pain-stakingly adjusted the settings by hand...

If the signal is visible with simple credentials and devices can't connect, it may be time to contact ASUS Tech Support about a defective new router. (It's not a Smart Connect issue, imo... Smart Connect with same SSIDs and default settings has worked well for me... on stock firmware.)

OE

 

[Grisu]

maybe false roaming parameters which control 2G/5G preferences and changeover.

 

[PeterV]

Is my router's 5 GHz radio broken? I can't really think of another explanation at this point. My settings are pretty standard, but if there's anything you'd recommend I try I would love to hear from you, thanks!

I have no solution for you.
But I can propose the additional test to check - is it HW issue or no ...
Please create the Guest 5GHz network, with simple WPA2 password, and check - is it accessible for your WiFi clients ...

 

[Ohia]

I have no solution for you.
But I can propose the additional test to check - is it HW issue or no ...
Please create the Guest 5GHz network, with simple WPA2 password, and check - is it accessible for your WiFi clients ...

Thanks. I just tried that, but I can't connect to the 5G guest network either. 2.4 GHz works fine! So I really am led to believe it is a hardware issue. I've requested an RMA with Asus, hoping that my replacement model will work as expected...

 

[sl4fko]

Have you tried different Control channels? Try below 120 for example...

 

[Ohia]

Have you tried different Control channels? Try below 120 for example...

Yes, I tried a couple in the 40s...

 

[Ohia]

Just to bring some closure to this thread: replacement model let my Mac connect just fine on 5 GHz. Even loaded previous settings, Smart Connect still worked as I expected it to. So I'm assuming it was a hardware issue!?

 

[ColinTaylor]

Even loaded previous settings,

You must never reload a "save settings" file from another router, even if that router is the same model. The settings file contains low-level hardware information (like MAC addresses) that are unique to each router. So whilst it may appear to work initially there's no guarantee that there will not be problems at a later date. You should now do a factory default reset and manual setup.

 

[Ohia]

You must never reload a "save settings" file from another router, even if that router is the same model. The settings file contains low-level hardware information (like MAC addresses) that are unique to each router. So whilst it may appear to work initially there's no guarantee that there will not be problems at a later date.

Is there actually any evidence for this? I fail to see why using .CFG files from an identical model (identical firmware revision too) would cause vague "problems at a later date". I just checked and my router's MAC address (as seen by my PC) is the same that's printed on the label on the back.
While I agree it's good to be cautious (I usually reset after flashing new firmwares), this seems to me a step too far. Happy to be proved wrong though...

 

[ColinTaylor]

Is there actually any evidence for this? I fail to see why using .CFG files from an identical model (identical firmware revision too) would cause vague "problems at a later date". I just checked and my router's MAC address (as seen by my PC) is the same that's printed on the label on the back.

Yes. I remember one forum member saying that he had reloaded the settings from his old RT-AC68U onto his new one, and was then using the old one as an AP. Both devices had the same LAN MAC address which caused his network to not function properly. I myself (running John's fork) have experimented with changing the MAC addresses in NVRAM and found them to be persistent also. I don't have an RT-AC86U and am not running Merlin's current firmware so it's possible that some of these settings are now regenerated every time the router boots up.

If you look at the output of nvram show | sort that is the information that you are restoring.

Looking at that output you will see lots of hardware settings that effect things like the wireless chipset and power amplifiers and also indicate the board revision, gpio settings, clock frequencies, ram refresh rates, rom revision, secret number, etc. So while a lot (but not all) of these settings will be the same for each router of the same model type, we have seen in the past that Asus can make subtle changes to the hardware that are not obvious just from the model number alone. Things like the type of RAM chips used, or slightly different clock frequencies.

While I agree it's good to be cautious (I usually reset after flashing new firmwares), this seems to me a step too far. Happy to be proved wrong though...

Given the information above and the fact that there are endless posts in these forums from people whose problems (not related to the settings file) were resolved by doing a factory reset, it seems wise to minimise the risk and not reload an old settings file when setting up a new router.

 

[Ohia]

I myself (running John's fork) have experimented with changing the MAC addresses in NVRAM and found them to be persistent also. I don't have an RT-AC86U and am not running Merlin's current firmware so it's possible that some of these settings are now regenerated every time the router boots up.

If you look at the output of nvram show | sort that is the information that you are restoring.

This is a a good point, but where is it written that the .CFG file is a direct dump of the entire NVRAM? (FWIW I'm using stock firmware at the moment, not Merlin's).

Looking at that output you will see lots of hardware settings that effect things like the wireless chipset and power amplifiers and also indicate the board revision, gpio settings, clock frequencies, ram refresh rates, rom revision, secret number, etc. So while a lot (but not all) of these settings will be the same for each router of the same model type, we have seen in the past that Asus can make subtle changes to the hardware that are not obvious just from the model number alone. Things like the type of RAM chips used, or slightly different clock frequencies.

Given the information above and the fact that there are endless posts in these forums from people whose problems (not related to the settings file) were resolved by doing a factory reset, it seems wise to minimise the risk and not reload an old settings file when setting up a new router.

Agreed, although so far everything seems to be going well - and I don't fancy entering all my DHCP and port forwarding settings manually for the umpteenth time just yet...

 

[ColinTaylor]

This is a a good point, but where is it written that the .CFG file is a direct dump of the entire NVRAM? (FWIW I'm using stock firmware at the moment, not Merlin's).

The cfg file is created by the "nvram save" command which dumps the nvram partition (mtdblock1). That file is encoded but you can see the contents by using something like WrtSettings. You can then confirm that they contain the same data.

EDIT: I have to correct myself to some extent here . The above is still true, the backup file does contain a copy of the entire nvram. However looking at the nvram restore code it looks like it is doing some filtering based on the router defaults. It's rather difficult for me to follow but it appears to be attempting to minimise some of the potential problems when restoring to the exact same model and firmware version.

 

[ColinTaylor]

Agreed, although so far everything seems to be going well - and I don't fancy entering all my DHCP and port forwarding settings manually for the umpteenth time just yet...

To ease the pain many people use the "nvram" command to dump just the DHCP and/or port forwarding settings to a text file so that they can be reloaded after a factory reset. Because you're just reloading this specific information it doesn't suffer the potential problems mentioned above.

 

[Ohia]

The cfg file is created by the "nvram save" command which dumps the nvram partition (mtdblock1). That file is encoded but you can see the contents by using something like WrtSettings. You can then confirm that they contain the same data.

Cool, I never heard of WrtSettings, I will use it to compare the two CFG files and see where they differ!

EDIT: I have to correct myself to some extent here . The above is still true, the backup file does contain a copy of the entire nvram. However looking at the nvram restore code it looks like it is doing some filtering based on the router defaults. It's rather difficult for me to follow but it appears to be attempting to minimise some of the potential problems when restoring to the exact same model and firmware version.

Are you talking about the actual source code (at least the GPL version of it)? I'm assuming it's on github. If you happen to know where the relevant code is, I'd love to have a browse through...
Thanks for your replies!

 

[ColinTaylor]

Are you talking about the actual source code (at least the GPL version of it)? I'm assuming it's on github. If you happen to know where the relevant code is, I'd love to have a browse through...

Yes. I'm looking at Merlin's code but it's based on Asus' GPL so I'd expect this part to be mostly, if not entirely, the same.

I was looking here, here and here.

 

[sfx2000]

You must never reload a "save settings" file from another router, even if that router is the same model. The settings file contains low-level hardware information (like MAC addresses) that are unique to each router. So whilst it may appear to work initially there's no guarantee that there will not be problems at a later date. You should now do a factory default reset and manual setup.

I agree - clear out things and start over...