Asuswrt-Merlin 380.58 is now available

[Blinkyz]

For the first question = Risky
For the 2 nd question= " Is there a way to stop/suspend scanning as his drive content doesn't change very often " Yes in the new Tweak and Hack section in 380.58

 

[BreakingDad]

Just wondering how come there is a 380.58 Merlin f/w when the official is only on 378. ? rt-n66u

 

[visortgw]

Just wondering how come there is a 380.58 Merlin f/w when the official is only on 378. ? rt-n66u

ASUS RT-N66U/RT-AC66R/RT-AC66U Firmware version 9.0.0.4.380.2695 beta was released 28 March.

 

[RMerlin]

Just wondering how come there is a 380.58 Merlin f/w when the official is only on 378. ? rt-n66u

The core code is the same across all models, so you can take newer firmware source code and use it on "older" models. The only difference lies in the closed-source components which are model-specific, and they were close enough to be able to reuse them with the 380 codebase with only a few workarounds.

 

[mxmln]

Thanks for the great work!

There is an issue in 380.58, I noticed in 380.57 already. In Adaptive QOS, if you use customize mode and change the order of the services, after pressing the save button, the QOS radio button is changing to Bandwidth Limiter. So it is not possible for me to change the order of the services in customize mode with Adaptive QOS.

Using Safari 9.1

 

[Eric Lieb]

No the Asus FW has no issues.
Currently I am on the 380.2695 Beta and have no issues. Same for version 378.9533. (Both RT-AC66U)

Are you seeing any 2.4 ghz lockups on 380.2695? I have been experiencing that on my AC66U using MerlinWRT 380.58 and wondering if it is my router of the firmware.

 

[Weaselboy]

Thanks for the great work!

There is an issue in 380.58, I noticed in 380.57 already. In Adaptive QOS, if you use customize mode and change the order of the services, after pressing the save button, the QOS radio button is changing to Bandwidth Limiter. So it is not possible for me to change the order of the services in customize mode with Adaptive QOS.

Using Safari 9.1

I had some issues getting QOS settings to stick in Safari also, but it worked fine in Chrome. Give Chrome a try.

 

[mxmln]

I had some issues getting QOS settings to stick in Safari also, but it worked fine in Chrome. Give Chrome a try.

Thank you. Works as expected in Chrome.

 

[daweeze02]

I'm having trouble accessing the admin UI page. It was for working then suddenly it can't be reached.
Is there some kind cmd I can use to get it working again without rebooting? Maybe set the admin autolog out or enable both http and https authentication? I'm using https only. I have a AC68u.

I just upgraded from 357 on my nt66 and have the same issue where my admin page timesouts

 

[SonicX]

Are you seeing any 2.4 ghz lockups on 380.2695? I have been experiencing that on my AC66U using MerlinWRT 380.58 and wondering if it is my router of the firmware.

Never looked for that.
I only use the 5ghz for the media bridge

 

[snakebite3]

I just upgraded from 357 on my nt66 and have the same issue where my admin page timesouts

Asus is looking into it.

 

[Ryu Connor]

Asus RT-AC88U
Merlin Firmware 380.58
Factory Reset has been applied

The RT-AC88U using the 380.58 firmware in Media Bridge Mode results in the media bridge not forwarding IPv6 traffic from the Access Point.

The Access Point being used is an RT-AC88U using the 380.58 Merlin firmware. The Access Point does receive an IPv6 address and does distribute those address to stations (direct clients). All stations forward that traffic except for the Asus RT-AC88U in Media Bridge Mode.

Applying Alpha Merlin firmware 380.59 fixes this problem, but opens up a new issue I'll report in the 380.59 thread.

Edit: One last important detail. An IPv6 address is assigned to stations (clients) of the bridge, but the RT-AC88U Media Bridge refuses to forward that traffic (would appear to be a data link layer failure).

Using netsh to validate neighbor discovery informs that all local clients are unreachable and external resources like http://test-ipv6.com/ fail.

 

[Sethr]

I started getting sporadic drop issues. I first noticed it on 2.4N while streaming. All of a sudden 0.4MB, yet it shows 4 bars on the screen. My Blackberry started dropping the AC for 5-20 seconds then picking it right back up.

All of this started on the 380.58 Final. It was fine on the Alpha. I just moved to .59 Alpha and will see what happens.

 

[bobbydigital]

Asus RT-AC88U
Merlin Firmware 380.58
Factory Reset has been applied

I upgrade to this FW build on my AC68 router from a much older build (like 6 month old), and my port forwarding rules seem to not be working correctly. Some ports are forwarding and others are not.

admin@RT-AC68R-91F8:/tmp/home/root# iptables -t nat -L -v | grep DNAT
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:22000 to:192.168.1.161:22000
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:2222 to:192.168.1.161:2222
    0     0 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:1194 to:192.168.1.161:1194
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:11269 to:192.168.1.105:4242
    0     0 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:52216 to:192.168.1.105:52216
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:52216 to:192.168.1.105:52216
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:23555 to:192.168.1.161:32400
   18   968 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:39211 to:192.168.1.105:39211
   18  2087 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:39211 to:192.168.1.105:39211
    0     0 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:52910 to:192.168.1.133:16402
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:12651 to:192.168.1.133:4242

I was having trouble with all the port forwarding rules until I pulled router power for 30s and rebooted. Now 2222/tcp works, but 1194/udp does not.

When I installed this firmware, I followed the release notes instructions and did a full factory reset so that's no the issue.

I read a few posts back about a suspicion that DoS protection on the Firewall settings page was affecting port forwarding but I've verified that mine is already off.

Any ideas?

 

[john9527]

Any ideas?

As a test, can you try toggling the state of UPNP (if it's on, turn it off and vice versa).

 

[bobbydigital]

As a test, can you try toggling the state of UPNP (if it's on, turn it off and vice versa).

I toggled uPNP to Off, saved, then back on and saved. After I did the second save, everything hung and couldn't get internet access (although my wifi connection was still working).

I had to yank power cord and power back on to get back in business.

Still no luck with port forwarding working though. iptables shows this:

admin@RT-AC68R-91F8:/tmp/home# iptables -t nat -L -v | grep DNAT
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:22000 to:192.168.1.161:22000
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:2222 to:192.168.1.161:2222
    1    28 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:1194 to:192.168.1.161:1194
    1    80 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:60845 to:192.168.1.105:60845

But port scan shows that 2222/tcp is up, but none of the 3 others are working. All show as closed.

 

[RMerlin]

Still no luck with port forwarding working though. iptables shows this:

admin@RT-AC68R-91F8:/tmp/home# iptables -t nat -L -v | grep DNAT
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:22000 to:192.168.1.161:22000
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:2222 to:192.168.1.161:2222
    1    28 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:1194 to:192.168.1.161:1194
    1    80 DNAT       udp  --  any    any     anywhere             anywhere             udp dpt:60845 to:192.168.1.105:60845

But port scan shows that 2222/tcp is up, but none of the 3 others are working. All show as closed.

Port scanners typically only test TCP, they don't test UDP. You can see here that your two UDP forwards are working, there's been one packet logged on each of them.

 

[tsunami2311]

the problem I was having with certian websites loading slow or missing images, when using OPENDNS I seemed to resolved by going back to 380.57. as i cant repoduce the problem like I was able to half hour again when I test opendns on 350.58

25 minutes after this when I Was all done puting my QOS and Mac address acceptations back in the issue started again.

So i guess it not FW issue

 

[jcarrra]

When I go to the download link in post 1 > Main download site (hosted by Mediafire) > RT-AC66U(folder) > Beta...
and download file
RT-AC66U_380.58_beta1-g985d54f.zip
the .trx file in it has an SHA256 that DOES NOT MATCH the one shown on the download page at http://asuswrt.lostrealm.ca/download...

but it DOES match the one in the test file included with the zip.
That of course does not prove integrity since if trx was modified, it would be trivial to put a matching SHA into the text file that accompanies it.
The SHA256 for the downloaded file is
554ff3809ccf1e9d590fffd4c9845c1848e1d424156f79f1122c70452c228b79.
Is that correct?
And if so, should that not be the one on the web page?

 

[RMerlin]

When I go to the download link in post 1 > Main download site (hosted by Mediafire) > RT-AC66U(folder) > Beta...
and download file
RT-AC66U_380.58_beta1-g985d54f.zip
the .trx file in it has an SHA256 that DOES NOT MATCH the one shown on the download page at http://asuswrt.lostrealm.ca/download...

but it DOES match the one in the test file included with the zip.
That of course does not prove integrity since if trx was modified, it would be trivial to put a matching SHA into the text file that accompanies it.
The SHA256 for the downloaded file is
554ff3809ccf1e9d590fffd4c9845c1848e1d424156f79f1122c70452c228b79.
Is that correct?
And if so, should that not be the one on the web page?

That would be because you downloaded 380.58 beta 1 rather than 380.58, which is what is listed on the website.