Asuswrt-Merlin 380.59 is now available

[jeff288]

I've upgraded to ver. 380.59 and quickly noticed that I'm not getting the full speed in my connections.

Currently I have a Gig connection with speedtest results ranging from 900 Mbps - 974 Mbps.

The firmware 380.59 beta appeared to work fine and then once it came out of beta I updated the new 380.59 firmware and noticed my speeds maxed out at 500-600 Mbps.

Speeds went back to normal when I directly wired into my PC and bypassed the router.

I factory reset the 380.59 release and tweaked a few settings and get the same 500-600 Mbps results.

The only solution I've found so far was to downgrade to 380.58 as it works fine.

Just a heads up! Any possible solutions?

At those speeds, make sure CTF is enabled. Also it's usually helpful to mention the router you have.

Dat ping! Dem speeds! Ummph!

 

[Jheroen]

I was still on .55 when i updated last week to this build, i mention now that my android phone is very quick unloaded, i guess some battery drain is active from the router that wasn't before... can anyone confirm this?

I will revert back to .55 with a factory reset and manual reconfig

 

[illfated]

so is it recommended not to update to the latest 380_3264, or soon newer ones if I plan to use Merlin later on?

 

[charlie2alpha]

so is it recommended not to update to the latest 380_3264, or soon newer ones if I plan to use Merlin later on?

I would say yes until things clear up about how third party firmware can be made certified/compatible and therefore flashable. Using the recovery tools for flashing is something that is only supposed to be done in an emergency (bricked router) not the normal procedure.

 

[JMB64]

I think there is an issue with the 380.59 code and Apple Airplay. I am not sure if it is in the closed source Asus or Quantenna code as the issue happens on both the 2.4Ghz network and the 5Ghz network.

I have consistent drop outs of Airplay plus my attached Airplay speaker keeps disappearing from my AirportExpress and does not show up as an available Airplay speaker even though Airport Utility shows the device is up and running. My speaker also drops out of my Asus 87U's device list and network map and the embedded web server link off the IP address does not show up or work. Rebooting the Airport Express only temporarily fixes the problem. I reverted back to 380.58 after completely replacing the Airport Express, trying different Apple firmware, checking network cables, and clearing the Asus's NVRAM and rebooting with a fresh config to no avail. The issue is now gone as I am back on 380.58.

I let Eric know about the problem as I am sure it is not his issue but something Asus or Quantenna did in some of their closed source code.

 

[charlie2alpha]

I think there is an issue with the 380.59 code and Apple Airplay. I am not sure if it is in the closed source Asus or Quantenna code as the issue happens on both the 2.4Ghz network and the 5Ghz network.

I have consistent drop outs of Airplay plus my attached Airplay speaker keeps disappearing from my AirportExpress and does not show up as an available Airplay speaker even though Airport Utility shows the device is up and running. My speaker also drops out of my Asus 87U's device list and network map and the embedded web server link off the IP address does not show up or work. Rebooting the Airport Express only temporarily fixes the problem. I reverted back to 380.58 after completely replacing the Airport Express, trying different Apple firmware, checking network cables, and clearing the Asus's NVRAM and rebooting with a fresh config to no avail. The issue is now gone as I am back on 380.58.

I let Eric know about the problem as I am sure it is not his issue but something Asus or Quantenna did in some of their closed source code.

Hmm, Apple devices use IGMP I think, can you try this and see if it makes any difference? Post #390

 

[JMB64]

Hmm, Apple devices use IGMP I think, can you try this and see if it makes any difference? Post #390

Charlie,

The issue IS with 380.59 if you read my post. 380.58 works fine and I had to revert back to it to make the Airplay issue go away.

 

[drummer914]

I've upgraded to ver. 380.59 and quickly noticed that I'm not getting the full speed in my connections.

Currently I have a Gig connection with speedtest results ranging from 900 Mbps - 974 Mbps.

The firmware 380.59 beta appeared to work fine and then once it came out of beta I updated the new 380.59 firmware and noticed my speeds maxed out at 500-600 Mbps....

I noticed the same thing. It's consistently a little slower. I ran multiple speed tests from different sites and never got above ~700 Mbps download until I reverted back to .58. RT-AC68P.
380.58 Speeds:

380.59 Speeds:

 

[cybrnook]

Asus already made a stick with their information. I don't have any additional information myself to add yet.

@RMerlin would you happen to have a link to Asus's sticky? I could not find it.

 

[oranheim]

I have two AC87U where one is set up as AP and the other as Media Bridge. After extensive testing I haven't experienced too many problems, but I do share some of the reports already mentioned in this thread. Like DLNA issues. However, it seems to be quite stable for my part, though I have found issues with fixed channels and channel avails.

I only see the following channels for 5G: 36, 40, 44, 48, 149, 153, 157, 161

I've also noticed that when I configure a fixed channel they are not respected. If I choose 161, it falls back to 157. When I configure back and forth I'm able to land on the right channel

I did of course a full reset after upgrade

Shouldn't the channel range 50 - 144 be available too?

My bl_version=1.0.3.2 (US).

 

[jrmwvu04]

Shouldn't the channel range 50 - 144 be available too?

My bl_version=1.0.3.2 (US).

If you're in the US, no. The channels you listed as available are the normally available channels. The DFS channels are commonly avoided in consumer products.

 

[oranheim]

If you're in the US, no. The channels you listed as available are the normally available channels. The DFS channels are commonly avoided in consumer products.

Thanks! That explains it. How about 165, shouldn't that be available?

 

[jrmwvu04]

Thanks! That explains it. How about 165, shouldn't that be available?

Channel 165 is sort of an oddity for some reason that I don't entirely understand. The shortest explanation is that it's quirky with some hardware and is hidden from use as it doesn't always work reliably.

 

[RMerlin]

@RMerlin would you happen to have a link to Asus's sticky? I could not find it.

http://www.snbforums.com/threads/asus-firmware-will-change-the-verification-method.32357/

 

[cybrnook]

http://www.snbforums.com/threads/asus-firmware-will-change-the-verification-method.32357/

Thanks @RMerlin , I was searching Asus's site

 

[dfran1]

Uptime 6 days 18 hours 26 minute(s) 31 seconds
RT-AC5300

I had a strange wifi to lan device control problem this morning. I did not see this on the alpha 2 4-5-16 (maybe I did not let it run long enough, though I thought I did). The problem was my app on my iPhone that controls a LAN device had a hard time finding it, actually I had to manually select it in the app after the app searched for it several times, this problem has not shown its ugly head since the bad old 87 days. I was the only one home, not much traffic at all at the time if any, I was able to do all other stuff on the iPhone (emails, web,.....).

May 13 23:08:20 disk_monitor: Got SIGALRM...
I have disabled all disk functions from day one, what is this?

May 18 02:00:13 rc_service: rc 9243:notify_rc restart_wrs
I looked it up and found this thread from a year ago
NAT loopback ? Mine is set to Asus, as merlins won't work for me and my NVR. (I always set it to Asus, even the alpha)

May 20 08:24:28 rc_service: httpd 524:notify_rc restart_wlcscan
I did a search and found some reference to changing the Preamble Type to short is the fix, not sure if it will?

I did not reboot the router yet, all I did was change the preamble to short so far.

If I see the problem again I will revert back to the alpha (I have it) and test further.

 

[CiscoX]

May 18 02:00:13 rc_service: rc 9243:notify_rc restart_wrs
I looked it up and found this thread from a year ago
NAT loopback ? Mine is set to Asus, as merlins won't work for me and my NVR. (I always set it to Asus, even the alpha)

This one comes from the TrendMicro AiProtection signature file, it updates when new signature file is available, The update used to happen around 02:00 military time

 

[z4r9]

Hoping someone can help me understand a default setting decision I noticed whilst tweaking the RT-AC87U running Asuswrt-Merlin 380.59:

Memory Management: Regularly flush caches (default: Yes)

Coming from a Linux background, I'm quite comfortable with having no memory "free" because I understand how buffers / cache work. The only time I've had to force flush in x86 Linux is under rare circumstances where something was badly broken. Is this different on ARM somehow?

 

[CiscoX]

May 13 23:08:20 disk_monitor: Got SIGALRM...
I have disabled all disk functions from day one, what is this?

From RMerlin:

This message is normal.

 

[dfran1]

From RMerlin:

This one comes from the TrendMicro AiProtection signature file, it updates when new signature file is available, The update used to happen around 02:00 military time

Thank You for both!