What's new

ASUS RT-AC68U Firmware version 3.0.0.4.374.4561 is out

  • 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!

It appears that newer units manufactured in 2014 (as noted on the box) were shipped with the upgraded bootloaders.

To check this, if you have Merlin's firmware you can see the Bootloader version under Tools > Sysinfo (Not Network Tools).

If you don't have Merlin's firmware and you can telnet or SSH into the router, you can pull the version by using the command:

Code:
nvram get bl_version

Configuring the router... What is the latest bootloader?

Gửi từ SM-N900 của tôi bằng cách sử dụng Tapatalk
 
It appears that newer units manufactured in 2014 (as noted on the box) were shipped with the upgraded bootloaders.

To check this, if you have Merlin's firmware you can see the Bootloader version under Tools > Sysinfo (Not Network Tools).

If you don't have Merlin's firmware and you can telnet or SSH into the router, you can pull the version by using the command:

Code:
nvram get bl_version

I preordered mine and got one when it first came out in the USA. So anyone else have an older non upgraded router you are having an issue with reboots?
 
I preordered mine and got one when it first came out in the USA. So anyone else have an older non upgraded router you are having an issue with reboots?

I have the suspicion that mine was bought from Best Buy in the US when they had a short sale for $119. It was resold to me at a discount to the current Canadian price. I do not see any RT-AC68R in Canadian stores.

Mine was manufactured in 2013. My Bootloader is 1.0.1.1. I have had this unit running for 1 week now. No random reboots.
 
Yes!!! It is 1.0.1.6 now! Current job is tik tak... 5 min online now...

Gửi từ SM-N900 của tôi bằng cách sử dụng Tapatalk

Very good. Keep on counting. You're on an older firmware, so I hope you do not experience any restarts.

Keep us updated.
 
Very good. Keep on counting. You're on an older firmware, so I hope you do not experience any restarts.

Keep us updated.

No... Using 583 is very good and no reboot issue. Now I upgraded to 4561 and keep on seeing the system log to know if the router is rebooted.
 
My Bootloader is 1.0.1.1 on the 86u and I get reboots if I'm past Aplha 4 (which has been up without a reboot for 24hrs since install). Both my 66u have been up over 4 days without a reboot since install of alpha 4 (Bootloader is 1.0.1.4)
 
No one responded to me when I asked if everyone who was having the reboot issue was on the newest Bootloader (1.0.1.6). This was what I wanted to know, because I am on 1.0.1.1 and I haven't experienced a random reboot yet.

The reboot issue hasn't been solved yet. I can not say for certain that you will get reboots, but I doubt that will happen. It appears to be a firmware problem, because when people downgrade to older firmwares the problem goes away.

I'm on 1.0.1.6, it shipped with that bootloader. I have tried the latest ASUS firmware and RMerlin's alpha 8 and 9, no stability.

Now I'm on alpha 4 and no reboots so far, 32 1/2 hours uptime atm, keeping fingers crossed...
 
To help with your data analysis...

I'm in the reboot category of 4432/4561.
I'm one of the original pre-order US folks also ... still on 1.0.1.1.
 
I assume that boot-loader versions are probably a bit different for each models...but just to chime in...

My AC56U...current Asus firmware 4561
Boot loader: 1.0.1.9

I don't think there ever was a DDR or boot-loader update tool for this model. If I recall, the RAM upgrade code was in one of the firmware updates.
 
After troubleshooting my overclocking issue with BL 1.0.1.1, I ended up flashing this official firmware.

I now confirm that builds 40_alpha7, alpha8, alpha9, and ASUS' official 4561 have the minor issue with 5GHz Channel bandwith set to 40MHz. The GUI stops showing any values for Channel Control and Extension Channel.
 
Last edited:
IPv6 works with RMerlin's 40_alpha9 now.

Will now time for any reboots with the new bootloader 1.0.1.6.
 
Here are the valid clock rates:

Code:
static unsigned int cpu_clock_table[] = {600, 800, 1000, 1200, 1400, 1600};
static unsigned int ddr_clock_table[] = {333, 389, 400, 533, 666, 775, 800};

If the values aren't in these tables, it reverts back to 800/533.

I dont think this values are so much accurate:

admin@proxy:/tmp/home/root# nvram get clkfreq
1300,800 => 1300 is accepted and its not on the CPU_CLOCK_TABLE and it does not revert to default speed of 800/666 (new BL default ddr speed)
admin@proxy:/tmp/home/root# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 2798.38

processor : 1
BogoMIPS : 2798.38

Features : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Hardware : Northstar Prototype
Revision : 0000
Serial : 0000000000000000

--------------------------------------------------------------------------------

admin@proxy:/tmp/home/root# nvram get clkfreq
1600,800 => After testing 3 different units, only one was able to achieve this speeds
admin@proxy:/tmp/home/root# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 3298.44

processor : 1
BogoMIPS : 3298.44

Features : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Hardware : Northstar Prototype
Revision : 0000
Serial : 0000000000000000
 
Last edited:


I dont think this values are so much accurate:

admin@proxy:/tmp/home/root# nvram get clkfreq
1300,800 => 1300 is accepted and its not on the CPU_CLOCK_TABLE and it does not revert to default speed of 800/666 (new BL default ddr speed)
admin@proxy:/tmp/home/root# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 2798.38

processor : 1
BogoMIPS : 2798.38

Features : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Hardware : Northstar Prototype
Revision : 0000
Serial : 0000000000000000

--------------------------------------------------------------------------------

admin@proxy:/tmp/home/root# nvram get clkfreq
1600,800 => After testing 3 different units, only one was able to achieve this speeds
admin@proxy:/tmp/home/root# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 3298.44

processor : 1
BogoMIPS : 3298.44

Features : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Hardware : Northstar Prototype
Revision : 0000
Serial : 0000000000000000

Someone on this forum was overclocking their AC56U to 900,666 and the BogoMIPS they posted corresponded to a CPU clock rate of 1000MHz.

Have you been able to push your unit to 1400 and run the command for BogoMIPS? Perhaps the nvram rounds up the clock speeds that are not in the clock table to the next clock speed that is.

I'm just assuming here based on the other user running 900,666.
 
Update: 17 hours online with 4561 FW and New Bootloader. But still waitting because the last online time with 4561 FW is about 23h. Hoping the reboots issue gone.
 
Someone on this forum was overclocking their AC56U to 900,666 and the BogoMIPS they posted corresponded to a CPU clock rate of 1000MHz.

Have you been able to push your unit to 1400 and run the command for BogoMIPS? Perhaps the nvram rounds up the clock speeds that are not in the clock table to the next clock speed that is.

I'm just assuming here based on the other user running 900,666.

Yes, thats correct.

1300 = 1400 :)
 
Reading this thread...I realized I haven't checked my router's uptime. And it's 18h :(
Nobody was home at that time. No laptop or tablet on. Just my 2 Synologys were running. And my router is just doing routing. DHCP on WAN, no "exotic" services active on the router. Just a router. NAT and few ports forwarded.
Log shows nothing in particular.
Odd.

I hope somebody is working with Asus and they will soon spot out the problem and fix it into a new firmware. If I will notice one more reload, I will try contacting Asus and maybe I will be able to collect data for them.
 

Latest threads

Sign Up For SNBForums Daily Digest

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