What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

RT-AX86U Pro occasionally doesn't recognize login until reboot

Chulamin

Occasional Visitor
I'm not sure how common this is, but occasionally I can't login to my fully updated stock RT-AX86U Pro without rebooting first. It still works fine but it just doesn't recognize the user name and/or password until the router is rebooted. There is no error other than invalid user. Then everything is back to normal for the next few weeks or even months. It's unpredictable and has been happening for at least the past year. it's not a huge problem, I'm just wondering if anyone else has expereiencd this. Thanks.
 
Just to confirm if you can access the router's GUI, are you running ASUS RT-AX86U Pro Firmware version 3.0.0.6.102_34349? Or some other firmware version?

How is the device you are using to log into the router connected to the router? By Ethernet wire, by WiFi, by Guest Network Pro WiFi/VLAN, by remote access outside the local LAN, by Asus router app, etc.? If using a web browser have you tried different web browsers and or different local network devices?

Did you have AiCloud active, and or any sort of router GUI, or SSH, remote access enabled?

As a last resort when there are weird router issues, perform a hard factory reset followed by a manual configuration (do not import a saved router.cfg file).
 
It happened to me with the BT92U. Turned out its due to router system time being way off like back to year 19xx somethig. I dont know why it lost the system time but whenever login issue happens, its the system time.
 
Like I said in my post, fully updated stock firmware. Connecting via WiFi from a Surface Pro tablet using Edge. I know the issue is the router and I don't intend to kill a mosquito with a sledge hammer because the problem is so minor and infrequent that don't want to spend much time investigating. I was just wondering if anyone else has had a similar experience. If not, I'll just drop the issue unless it becomes a more frequent event. Maybe it'll be cleared up with the next firmware release. Thanks.
 
It happened to me with the BT92U. Turned out its due to router system time being way off like back to year 19xx somethig. I dont know why it lost the system time but whenever login issue happens, its the system time.
That sounds like a possibility. I'll check that the next time it happens...if I can connect before rebooting.
 
If you're running IPv6 then closing a gui session and logging back in within 2 minutes (or logging in from another device) can cause this.
Just a suggestion based on observation.
 
That sounds like a possibility. I'll check that the next time it happens...if I can connect before rebooting.
Actually....that's exactly what seems to have happened. I checked the router logs and the previous date shows as December 31 and the one prior that shows as July 3. There were also a ton of odd entries showing on the Dec. 31 date. The last entry for Dec. 31 was an NTP update. Not sure what caused it but I check the logs if/when it happens again. Could be the firmware or maybe a power spike. Thanks!
 
The Dec 31 date appears in the log when the router boots up. That in itself wouldn't cause a "invalid user" error when trying to log in.
 
Just an aside... does Asus use any Merlin coding in it's stock firmware? I noticed a number of references to it in the logs:

Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): PMD Setup 50MHz, 10.3125GHz VCO programming
Dec 31 17:00:20 kernel: MerlinSupport::merlin_wait_uc_active(): wait 50us comclks for micro to be up...
Dec 31 17:00:20 kernel: MerlinSupport::merlin_wait_uc_active(): Checking uc_active passed ...
Dec 31 17:00:20 kernel: MerlinSupport::merlin_wait_uc_active(): micro is ready for command ...
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 9. Configure Core level regsiter
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 10. Set core_congif_from_pcs
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): RAM variable vco_rate is 19
Dec 31 17:00:20 kernel: MerlinSupport::merlin_cfg_core_ram_var(): program core_config_word 0x26 to ram address 0x20000200 ...
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 12. Reset Datapath (core)
Dec 31 17:00:20 kernel: MerlinSupport::merlin_reset_datapath_core(): Datapath Reset (core) in progress
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 13. Lane Configuration
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 13.a. Configure lane registers
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): RAM variable an_enabled is 0
Dec 31 17:00:20 kernel: MerlinSupport::merlin_cfg_lane_ram_var(): program lane_config_word 0x0 to ram address 0x20000300 ...
Dec 31 17:00:20 kernel: MerlinSupport::merlin_lane_config_speed(#2):
Dec 31 17:00:20 kernel: MerlinSupport::CONFIGURING FOR FORCE 1G
Dec 31 17:00:20 kernel: MerlinSupport::merlin_lane_config_speed(): Core #0 Lane #0 PMD Lock Speed Up programming
Dec 31 17:00:20 kernel: INFO MerlinSupport::merlin_lane_config_speed(): END Merlin core #0 lane #0 Initialization procedure
Dec 31 17:00:20 kernel: MerlinSupport::merlin_chk_pll_lock(): Checking Core #0 PLL Lock Status
Dec 31 17:00:20 kernel: MerlinSupport::merlin_chk_pll_lock(): PLL Locked
Dec 31 17:00:20 ker
 
Just an aside... does Asus use any Merlin coding in it's stock firmware? I noticed a number of references to it in the logs:

Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): PMD Setup 50MHz, 10.3125GHz VCO programming
Dec 31 17:00:20 kernel: MerlinSupport::merlin_wait_uc_active(): wait 50us comclks for micro to be up...
Dec 31 17:00:20 kernel: MerlinSupport::merlin_wait_uc_active(): Checking uc_active passed ...
Dec 31 17:00:20 kernel: MerlinSupport::merlin_wait_uc_active(): micro is ready for command ...
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 9. Configure Core level regsiter
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 10. Set core_congif_from_pcs
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): RAM variable vco_rate is 19
Dec 31 17:00:20 kernel: MerlinSupport::merlin_cfg_core_ram_var(): program core_config_word 0x26 to ram address 0x20000200 ...
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 12. Reset Datapath (core)
Dec 31 17:00:20 kernel: MerlinSupport::merlin_reset_datapath_core(): Datapath Reset (core) in progress
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 13. Lane Configuration
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): Step 13.a. Configure lane registers
Dec 31 17:00:20 kernel: MerlinSupport::merline_speed_set_core(): RAM variable an_enabled is 0
Dec 31 17:00:20 kernel: MerlinSupport::merlin_cfg_lane_ram_var(): program lane_config_word 0x0 to ram address 0x20000300 ...
Dec 31 17:00:20 kernel: MerlinSupport::merlin_lane_config_speed(#2):
Dec 31 17:00:20 kernel: MerlinSupport::CONFIGURING FOR FORCE 1G
Dec 31 17:00:20 kernel: MerlinSupport::merlin_lane_config_speed(): Core #0 Lane #0 PMD Lock Speed Up programming
Dec 31 17:00:20 kernel: INFO MerlinSupport::merlin_lane_config_speed(): END Merlin core #0 lane #0 Initialization procedure
Dec 31 17:00:20 kernel: MerlinSupport::merlin_chk_pll_lock(): Checking Core #0 PLL Lock Status
Dec 31 17:00:20 kernel: MerlinSupport::merlin_chk_pll_lock(): PLL Locked
Dec 31 17:00:20 ker
No. The word "Merlin" you're seeing is completely unrelated to RMerlin's firmware.
 
The Dec 31 date appears in the log when the router boots up. That in itself wouldn't cause a "invalid user" error when trying to log in.
I am not exactly sure how Asus implements the login mechnism but it is quite common that login relies on time-based mechanisms for session management or credential validation. If the router’s system time is significantly off , the server may reject login attempts due to mismatched timestamps.

If an ASUS router resets its system time on reboot without causing login issues, the problem reported by the original poster might stem from a timing issue where the Web UI becomes accessible before the router's system is fully initialized.
 
I am not exactly sure how Asus implements the login mechnism but it is quite common that login relies on time-based mechanisms for session management or credential validation. If the router’s system time is significantly off , the server may reject login attempts due to mismatched timestamps.
It wouldn't generate an "invalid user" error though. Well, not unless they've changed the login process and associated error messages (which I suppose is possible).

@Chulamin Next time this happens make a note of the exact error message.
 
Last edited:
does Asus use any Merlin coding in it's stock firmware?
They do, but it's unrelated to these long entries. Merlin, Longfin and Nihhau are Broadcom codenames for some of their network switches. These log entries are for the network switch loading its own internal firmware.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top