What's new

Asuswrt-Merlin 376.49 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!

AC 66u flashing problem

Dear Merlin,

with ref. to my tweet here is the description of my problem with AC66u router. I am very satisfied user of Your firmware, this the first time I have a flashing problem.

I have just received the confirmation e-mail for this forum.

I upgraded from 376.49_2 to the latest 376.49_4 and after that the router died, there was no communication with it. After several restarts I put it to restoration mode, the power LED is slowly flashing.

I start the restoration utilities, locate the fw file, press upload. The progress bar comes to 100% and then comes the message

FAILED TO RECOVER THE SYSTEM.

I tried several times with different versions of both Merlin and ASUS firmware, but the result is always the same. I used 2 versions of restoration utilities (the latest one 2.0.0 and also 1.9.0), I tried 2 computers, one with Windows 8.1, the second with Windows 7.

There are no cables connected to the router except LAN1 for computer connection and power cable. Router starts now to recovery mode.


What can I do to fix the problem?

Thanks for Your help, best regards

vladsuk
 
Dear Merlin,

with ref. to my tweet here is the description of my problem with AC66u router. I am very satisfied user of Your firmware, this the first time I have a flashing problem.

I have just received the confirmation e-mail for this forum.

I upgraded from 376.49_2 to the latest 376.49_4 and after that the router died, there was no communication with it. After several restarts I put it to restoration mode, the power LED is slowly flashing.

I start the restoration utilities, locate the fw file, press upload. The progress bar comes to 100% and then comes the message

FAILED TO RECOVER THE SYSTEM.

I tried several times with different versions of both Merlin and ASUS firmware, but the result is always the same. I used 2 versions of restoration utilities (the latest one 2.0.0 and also 1.9.0), I tried 2 computers, one with Windows 8.1, the second with Windows 7.

There are no cables connected to the router except LAN1 for computer connection and power cable. Router starts now to recovery mode.


What can I do to fix the problem?

Thanks for Your help, best regards

vladsuk

Double check that you are using the correct model, and that you did unzip the file before flashing it.

After the bar reaches 100%, still leave the router as is for another 10-20 minutes. Flashing in recovery mode is much slower than when done from within the firmware. Some models such as the RT-N66U can take up to 30-40 minutes to complete their recovery process. Once the process is completed, the router will automatically reboot itself - best way to know this has happened is the wifi LEDs coming back on after the reboot following a successfull flash.

I would also disable any security software and antivirus on your PC, and possibly try a different web browser.
 
With .49_2 I made port forward and my ps4 working good with open status. But after update to 49_4 my port no longer open.
 
Double check that you are using the correct model, and that you did unzip the file before flashing it.

After the bar reaches 100%, still leave the router as is for another 10-20 minutes. Flashing in recovery mode is much slower than when done from within the firmware. Some models such as the RT-N66U can take up to 30-40 minutes to complete their recovery process. Once the process is completed, the router will automatically reboot itself - best way to know this has happened is the wifi LEDs coming back on after the reboot following a successfull flash.

I would also disable any security software and antivirus on your PC, and possibly try a different web browser.

Router was now about one hour left in the "posterror" state, the power LED was on (not flashing), but WiFi LEDś are off. After power cycle it came again to restoration mode. (flashing power LED)

Fw versions are O.K.

What else can I do,pls?
 
Router was now about one hour left in the "posterror" state, the power LED was on (not flashing), but WiFi LEDś are off. After power cycle it came again to restoration mode. (flashing power LED)

Fw versions are O.K.

What else can I do,pls?

Try clearing the nvram before flashing.

  • Turn router off
  • Press and hold the WPS button
  • Turn router on
  • Wait 15-20 secs
  • If Power is flashing, try again the recovery tool
  • If not, turn it off, press and hold reset, turn it on, try again the recovery tool
  • Let the router sit for at least 30 mins after flashing

Also try my other previous suggestions such as using a different browser and disabling any security software.

If it still fails, then you might have defective flash, which causes the flash process to fail. The only way to troubleshoot things out at this stage would be through a serial cable connected to the internal serial port, so your best bet would probably be to have the router replaced under warranty.
 
With .49_2 I made port forward and my ps4 working good with open status. But after update to 49_4 my port no longer open.

There's been zero change related to the firewall or UPNP (in fact the vast majority of changes were only in the HTML pages). Try power cycling your PS4 to ensure it does re-establish its UPNP forwards.
 
There's been zero change related to the firewall or UPNP (in fact the vast majority of changes were only in the HTML pages). Try power cycling your PS4 to ensure it does re-establish its UPNP forwards.

I did like ten times and even reboot my router too.
 
Sadly, a lot of routers (including Asuswrt) allow the definition of a reservation outside the defined scope, which leads to issues such as encountered here.

Asus' own description at the top of the reservation table offers little in the way of help;

Manually Assigned IP around the DHCP list (Max Limit : 128)

Indicating, to me at least, IP's should be assigned outside (around) DHCP list.
 
Asus' own description at the top of the reservation table offers little in the way of help;



Indicating, to me at least, IP's should be assigned outside (around) DHCP list.

A lot got lost in the Chinese -> English translation of their webui, sadly.

As an additional reference to my explanation, the Windows Server DHCP server won't even let you define a reservation outside of the defined scope.

I remember there was a discussion on this topic elsewhere here in SNB a few months ago. If I remember correctly, the WRT1900AC won't let you allocate reservations from outside the defined scope either.
 
Try clearing the nvram before flashing.

  • Turn router off
  • Press and hold the WPS button
  • Turn router on
  • Wait 15-20 secs
  • If Power is flashing, try again the recovery tool
  • If not, turn it off, press and hold reset, turn it on, try again the recovery tool
  • Let the router sit for at least 30 mins after flashing

Also try my other previous suggestions such as using a different browser and disabling any security software.

If it still fails, then you might have defective flash, which causes the flash process to fail. The only way to troubleshoot things out at this stage would be through a serial cable connected to the internal serial port, so your best bet would probably be to have the router replaced under warranty.

THANK YOU VERY MUCH, I highly appreciate Your support.

After clearing the NVRAM router restarted ( when I released the WPS button) and came back with the fw used during restoration process. After downloading the backup cfg file it is up and running with the 376.49_4.
 
The real problem is, a lot of users got used to allocating static leases outside of the scope, which is wrong. People are mixing up reservations with static IPs.

A static IP is something you configure on the computer's network interface, and which must be outside of the DHCP range.

A DHCP reservation is an IP you reserve within your DHCP scope, so the DHCP server will always allocate the same IP.

In other words: any IP allocated by the DHCP server *must* be within the DHCP range, regardless of whether it's static or dynamic. The fact that the DHCP server can allocate an IP from outside its defined scope is a quirk/bug in itself.

Sadly, a lot of routers (including Asuswrt) allow the definition of a reservation outside the defined scope, which leads to issues such as encountered here.

The correct fix is to either enlarge your DHCP scope to include your reservations, or change your reservations to be within the defined scope. And if your goal is for an IP to be outside of the DHCP range, then you must configure it manually and not rely on the DHCP server to allocate an IP from outside its defined range.

OOPS, it seems I'm a sinner with regards to this, I actually had my DHCP range (2-254) covering my static IP range (2-20), but changed it..
I have seen any problem with this configuration, what can the result of this misconfiguration be?

I've been having some issues with my Macbook Pro retina taking it's sweet time to get the network operational after sleep mode, re-flashing and reconfiguring the router may have been improving the issue somewhat (placebo?).
 
That's caused by NAT acceleration, which causes a good portion of the traffic to bypass the router's network stack.

I have NAT acceleration (CTF) enabled and yet all traffic monitoring features and (from an earlier post) parental control features appear to be working perfectly! :confused:
 
On which page?

With an N66, on QoS tab, with "QoS to configuration" in the pulldown, there is a "QoS FAQ" link which takes me to a "Feedback" page on the Asus website. I think the link is to FAQ 1008718 but perhaps instead should be to 113967.
 
The calculation is fine. It looks at the range you defined on the DHCP page to determine the maximum number of lease.

The real problem is, a lot of users got used to allocating static leases outside of the scope, which is wrong. People are mixing up reservations with static IPs.

A static IP is something you configure on the computer's network interface, and which must be outside of the DHCP range.

A DHCP reservation is an IP you reserve within your DHCP scope, so the DHCP server will always allocate the same IP.

In other words: any IP allocated by the DHCP server *must* be within the DHCP range, regardless of whether it's static or dynamic. The fact that the DHCP server can allocate an IP from outside its defined scope is a quirk/bug in itself.

Sadly, a lot of routers (including Asuswrt) allow the definition of a reservation outside the defined scope, which leads to issues such as encountered here.

The correct fix is to either enlarge your DHCP scope to include your reservations, or change your reservations to be within the defined scope. And if your goal is for an IP to be outside of the DHCP range, then you must configure it manually and not rely on the DHCP server to allocate an IP from outside its defined range.

Merlin when I took my class in Cisco and MS that covered DHCP over 10 years ago the method of having a dynamic pool and a static reservations were covered in details. You can have the DHCP server hand reserved addresses outside of the dynamic ranges and the techniques I have been using are handled just fine in DNSMasq, MS DNS/DHCP, and Cisco DHCP.

The issue here is that ASUS has implemented a solution that assumes that the number ip's in the range is the number of leases the DNSmasq daemon will manage. I assumes all static reservations are within the range defined on the web page and sets the max managed to that value . If they are going to enforce that rule then they need to rethink the validation of IP addresses on that web page.

I think it makes more logical sense to have a small dynamic pool that doesn't co-mingle with the static reservations. That is how we do it at works also with over 1.5 million managed IP addresses via DHCP. Granted we are using Cisco as part of our network infrastructure.

As usual many capabilities of the core utilities of the router software are kept under lock and key via the web interface but this is one that should be accounted for.
 
In other words: any IP allocated by the DHCP server *must* be within the DHCP range, regardless of whether it's static or dynamic. The fact that the DHCP server can allocate an IP from outside its defined scope is a quirk/bug in itself.

Sadly, a lot of routers (including Asuswrt) allow the definition of a reservation outside the defined scope, which leads to issues such as encountered here.

The correct fix is to either enlarge your DHCP scope to include your reservations, or change your reservations to be within the defined scope. And if your goal is for an IP to be outside of the DHCP range, then you must configure it manually and not rely on the DHCP server to allocate an IP from outside its defined range.

Very helpful. I've long been puzzled by this. The heading "Manually Assigned IP around the DHCP list" would be a lot clearer the way Google translates the Chinese version "Manually specify the DHCP IP list", which follows your explanation. Better yet would be "Manually reserve IPs from DHCP".

Three other contributors of the confusion: I have several devices in the manually assigned list that are outside of the DHCP range, but in each case they are as you say addresses that are specified on the device, so I didn't realize putting them in the static list was a waste.

Another is in the client list--devices getting a reserved IP are labeled "static" not "DHCP".

Another is in the client list--these statically set devices show up in the client list with the reserved name and the same "static" label. That's a legacy of one of the Merlin improvements I think. Still helpful.

I'm not suggesting any change for noobs like me, not with this explanation.
 
That was not a fix, that was a flat out revert to the original hardcoded value, which was wrong.

The calculation in the latest GPL was correct, so I merged it back in.
I think a "fix" would be to not allow people to create reservations outside of the DHCP scope. This is how I have seen it handled in other home routers.
 
Last edited:
I have both an AC-68U and TM-1900. First runs as router, second as access point. Both had 376-49-2 firmware. I updated the AC-68 to 376-49-4 without any problem, but TM-1900 keeps on saying "Upgade Failed" and stays on 376-49-2. I tried both wireless and wired connections, reset to factory defaults but I still cannot upgrade it. Any other suggestions to try?
 
I have both an AC-68U and TM-1900. First runs as router, second as access point. Both had 376-49-2 firmware. I updated the AC-68 to 376-49-4 without any problem, but TM-1900 keeps on saying "Upgade Failed" and stays on 376-49-2. I tried both wireless and wired connections, reset to factory defaults but I still cannot upgrade it. Any other suggestions to try?
Am surprised you have been able to install any Merlin firmware at all. Wonder if anyone has figured out how to upgrade the TM-1900 in general.
 
Am surprised you have been able to install any Merlin firmware at all. Wonder if anyone has figured out how to upgrade the TM-1900 in general.

It was the first thing I did when I got it 3 months ago. I installed 376-47, then 376-48 and 376-49-2. But it does not accept any other firmware anymore. Any ideas?
 

Similar threads

Sign Up For SNBForums Daily Digest

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