Asuswrt-Merlin 380.57 is now available

[GG7]

Did the NAT Acceleration set to auto work for you? http://www.snbforums.com/threads/asuswrt-merlin-380-57-is-now-available.29308/page-10#post-226885

Nope. In fact, mine started out with that set to AUTO, and I turned it off to see if that might have an effect and it didn't one way or the other. I normally run with this feature turned off because I do a lot of online gaming on Xbox One, PS4 and the Wii U.

NAT acceleration is generally considered a major NO NO by all the major console/game network companies. So, I never have used the feature.

 

[MarkRH]

Nope. In fact, mine started out with that set to AUTO, and I turned it off to see if that might have an effect and it didn't one way or the other. I normally run with this feature turned off because I do a lot of online gaming on Xbox One, PS4 and the Wii U.

NAT acceleration is generally considered a major NO NO by all the major console/game network companies. So, I never have used the feature.

Well, with my 68U, after a factory reset and NAT acceleration was set to Auto, only CTF was enabled. I turned it off and then back to Auto and now CTF and FA are enabled and my daily/24-hour bandwidth monitors are working properly where at first they were not. So, might try it. Can always turn it back off.

 

[jerry6]

RT-AC87U as router, flashed from 378.56_2 to 380.57, working well in both versions.
RT-AC3200 as AP, flashed from stock firmware to 380.57, so far so good.
RT-AC66U & RT-AC66R as AP, flashed from 378.56_2 to 380.57, working well in both versions.

RT-AC66U & AC66R as repeater, worked well with 378.56_2, but not with 380.57. As reported by other users in earlier posts, the units kept rebooting (tested 2 units). Flashed back to 378.56_2, again no problem.

Warning: 380.57 does not work on RT-AC66U(R) as repeater.

Other than this, the new firmware is awesome. Thanks Merlin!

Or media bridge , at least in my case , tried all alpha and final builds

 

[Raiu]

Can anyone get time machine to work?

My sig is wrong on the FW ver. its current.

 

[bluepoint]

Did the NAT Acceleration set to auto work for you? http://www.snbforums.com/threads/asuswrt-merlin-380-57-is-now-available.29308/page-10#post-226885

Confirmed, setting "NAT acceleration" manually to disable breaks 2.4 GHz band's internet connection while 5GHz band is still working. The client can connect to the 2.4GHz band and getting an IP from the DHCP server but can't resolve websites, do ping and tracert as indicated in the wireless icon when mouse is hovered it says "no internet access". And this is in an RT-AC68P, it's reproducible by just disabling NAT acceleration.

Note: I don't use traffic analyzer(I believe this disables NAT acceleration automatically) which some are using and not experiencing the bug. That's the reason I specifically said disabling "NAT acceleration" manually.

 

[abwyatt]

I also had the 2.4G issue on my 68U. I did upgrade from 377.56_2 and then did a factory reset. Then I used John's tool to bring back my settings. Unfortunately the issue on 2.4G appeared. On 5G my clients worked normally. Then I tried to change channel with no luck.
What appeared to solve my problem was to go at LAN settings>Switch Control and put NAT Acceleration to Auto. When it was to "Disable" I had wifi connectivity issues.

Yes, I can confirm that the NAT acceleration setting is also causing my RT68U to have issues with 2.4 GHz. Disabling NAT acceleration will cause all 2.4 GHz clients to disconnect from WAN. Setting NAT acceleration to Auto restores 2.4 GHz WAN connectivity.

 

[kvic]

All them Asus people from Japan are on there 4 day holiday vacation but will be back tomorrow so lets hope this issue is at the top of the list..

It's so 1800's...Kal-EL is a wise man from the distant past.

Japan invaded and captured Taiwan in 1895 after the first Sino-Japanese War. That was also the beginning of Japan's invasions into many Asian countries in the 50 years that followed... until its eventual defeat in WWII.

Taiwan != Japan. The rest of your sentence is mostly right...

 

[Koguma]

Yes, I can confirm that the NAT acceleration setting is also causing my RT68U to have issues with 2.4 GHz. Disabling NAT acceleration will cause all 2.4 GHz clients to disconnect from WAN. Setting NAT acceleration to Auto restores 2.4 GHz WAN connectivity.

I wasn't sure what the issue was, but I did find that every firmware past 378.54_2 was causing stability issues. With this latest firmware, not only did 2.4Ghz get flaky, but the router needed to be reset every day. I've rolled back to 378.54_2 amd there's no more issues. There's definitely some issues with the latest firmware and the RT-68U/R router that goes beyond just 2.4GHz issuess with NAT acceleration.

 

[DaveMishSr]

There's nothing to "fix", as overclocking was never a supported feature. The bootloader values are now automatically overwritten at boot time by a closed-source component, therefore it will never be "fixed".

Honestly, overclocking isn't even needed. Since I went over to stock nvram clkfreq settings and no automated reboots I have noticed no performance decrease. My 2 Linksys/Cisco WUMC710 media bridges actually stay connected now so long as I don't start playing around with my router's configuration.

 

[RogerSC]

Back to 378.56_2 for me. I'll try the next 380 release. Doesn't look quite ready yet to me...maybe it's the new SDK, don't know.

 

[GG7]

I wasn't sure what the issue was, but I did find that every firmware past 378.54_2 was causing stability issues. With this latest firmware, not only did 2.4Ghz get flaky, but the router needed to be reset every day. I've rolled back to 378.54_2 amd there's no more issues. There's definitely some issues with the latest firmware and the RT-68U/R router that goes beyond just 2.4GHz issuess with NAT acceleration.

Has anyone else fully documented this change in the NAT to act as easily to alter the 2.4 band's internet connectivity as turning on a light switch?

I would definitely like to see this theory confirmed, so that if it is indeed connected I can pass this info along to my support contact at ASUS where I have an open ticket on this 2.4 bug.

Thanks!

 

[Rango]

Merlin quick question. RT-N66U is single core router and when i looked at the 66u log it still says it's split between two cores.

Won't this be a problem in 66u release ??
If this will be how to I revert that in nvram threw command?

- FIXED: Openvpn clients 3 through 5 were all run on the first CPU core. They are now properly alternated like the first two (odd on CPU1, even on CPU0)

 

[GG7]

Well, with my 68U, after a factory reset and NAT acceleration was set to Auto, only CTF was enabled. I turned it off and then back to Auto and now CTF and FA are enabled and my daily/24-hour bandwidth monitors are working properly where at first they were not. So, might try it. Can always turn it back off.

I would like to see what happens if someone who has never experienced this 2.4 GHz internet connection bug before, set their NAT Acceleration to DISABLE and document what happens. Does making this single change to a previously fully functioning router cause the 2.4 side to loose all internet connectivity for all connected devices?

I would prefer to see someone besides me try this experiment, because as I mentioned before, I don't have a choice when it comes to NAT acceleration, and my NAT setting didn't appear to make a difference with my 2.4 connections. I need to have that NAT Acceleration turned OFF to avoid multi-player issues with online gaming.

If the cause can be reduced to something as simple as this one feature's ON/OFF state, that would be HUGE! Wouldn't be of any help to me personally in terms of a temp workaround, but at least it points towards what needs to be fixed.

 

[Etz]

Merlin quick question. RT-N66U is single core router and when i looked at the 66u log it still says it's split between two cores.

Won't this be a problem in 66u release ??
If this will be how to I revert that in nvram threw command?

- FIXED: Openvpn clients 3 through 5 were all run on the first CPU core. They are now properly alternated like the first two (odd on CPU1, even on CPU0)

I dont`t think it could cause a problem.
As that router only has one core, there is nothing to split, eq. that code won`t function and nothing changes.

 

[Clavius]

380.57 seems to fix RT-AC56U's 2.4G problem.
I can use 40Hz channel bandwidth and keep full speed.
Awesome

 

[Selectaa]

I can confirm that on my R7000 Nighthawk the 2,4 GHz band got broken in 380.57, but disabling QOS so that I could set NAT Acceleration to Auto fixed the problem

 

[octopus]

I can confirm that on my R7000 Nighthawk the 2,4 GHz band got broken in 380.57, but disabling QOS so that I could set NAT Acceleration to Auto fixed the problem

Sorry but Netgear R7000 isnt supported by RMerlins fork.

Supported devices are ASUS:
* RT-N66U
* RT-AC66U
* RT-AC56U
* RT-AC68U
* RT-AC68P
* RT-AC87U
* RT-AC3200
* RT-AC88U
* RT-AC3100
* RT-AC5300

 

[Selectaa]

Sorry but Netgear R7000 isnt supported by RMerlins fork.

Supported devices are ASUS:
* RT-N66U
* RT-AC66U
* RT-AC56U
* RT-AC68U
* RT-AC68P
* RT-AC87U
* RT-AC3200
* RT-AC88U
* RT-AC3100
* RT-AC5300

Sorry, should have said that I'm running the Xwrt-Vortex firmware based on Merlin on my R7000. The rest of my family is running on ASUS routers so they're using "proper" Merlin firmware.
Nevertheless, I got the exact same problem with the Xwrt-Vortex firmware based on Merlin 380.57 and the same fix seems to work on both router platforms

 

[octopus]

Sorry, should have said that I'm running the Xwrt-Vortex firmware based on Merlin on my R7000. The rest of my family is running on ASUS routers so they're using "proper" Merlin firmware.
Nevertheless, I got the exact same problem with the Xwrt-Vortex firmware based on Merlin 380.57 and the same fix seems to work on both router platforms

Then you should use this forum for support: http://www.linksysinfo.org/index.php?threads/asuswrt-merlin-on-netgear-r7000.71108/

 

[geko53]

In conclusion, I am not saying changing the 2.4GHz channel is a fix for those having a problem with the RT-AC68U and the new driver. The problem may be that something in NVRAM is not being cleared and is therefore causing problems with the 2.4GHz radio for some people. If someone knows how to wipe NVRAM better than resetting to factory defaults, that may be the fix for this issue.

Neither changing channel nor wiping NVRAM ("NVRAM erase") did solve the problem in my case...

Ciao
Gerald