Asuswrt-Merlin 380.57 is now available

[tomislav]

ASUS seems to have removed the "Airtime Fairness" option in the 5 Ghz band... at least on the AC87U.

 

[metadethrax]

Regardin the speed issues I previously mentioned here (http://www.snbforums.com/threads/asuswrt-merlin-380-57-is-now-available.29308/page-6#post-226522), please check the two speedtests made with 378_56_2 (
http://www.speedtest.net/result/4949817036.png) and then with 380_57 (
http://www.speedtest.net/result/4949913251.png). Tests were performed with identical settings in my 68U (A1 HW revision).
Asus definitely screwed something in the 380, maybe Merlin has more information to share with us. Thank you!

 

[BoorZhyu]

Using RT-AC66U with both bands at home - 5G and 2.4G.
As at our building a lot of 2.4G networks I need to change the free chanel manually so when I try to set up 12 or 13 chanel after router reload at the menu always set up "auto" chanel - (can use only from 1 to 11 channels mannualy). Hope it will be corrected in next firmware.

 

[GG7]

Using RT-AC66U with both bands at home - 5G and 2.4G.
As at our building a lot of 2.4G networks I need to change the free chanel manually so when I try to set up 12 or 13 chanel after router reload at the menu always set up "auto" chanel - (can use only from 1 to 11 channels mannualy). Hope it will be corrected in next firmware.

I wonder if your issues have anything to do with this posted change to the ASUS version that this latest Merlin FW incorporates?

- Fixed wireless channel issue when set 2.4G channel in 12 or 13 (only for EU region)

You see that this was only supposed to effect routers being used in the EU region, but I always suspected that this change may still have caused the 2.4 GHz problems on the 68U and other models for all regions. Seemed like too much of a coincidence that the very first time I see the 2.4 band listed in the patch notes for a new update, we start having all these issues with the same section of the hardware.

 

[GG7]

Here is that entire list of patch notes taken from the ASUS firmware download page for the 68U:

ASUS RT-AC68U Firmware version 3.0.0.4.380.1031
- Release Notes –
- Fixed too many repeat information in system log.
- Fixed Traffic analyzer issue UI issue when changing the data.
- Fixed Adaptive QoS bandwidth setting issue.
- Fixed low samba transfer throughput issue when enable bandwidth limiter.
- Fixed web history related issue.
- Fixed abnormal bandwidth increasing in bandwidth monitor.
- Fixed VPN client UI issue when using Firefox.
- Fixed wireless channel issue when set 2.4G channel in 12 or 13 (only for EU region)
- Fixed dual wan ping time watch dog issue which might cause .false fail over to secondary wan.
- Fixed Bandwidth monitor and Web history UI issue which was caused by "<" or ">" in SSID.

 

[Volidon]

Looked through all the pages but didn't see anything on this. Does this version fix the wifi battery drain issue on a RT-AC87?

 

[jamestx10]

I finally had time and took the jump of updating my RT-N66U all the way from 374.41. I used the settings restore script and so far everything is working. Thanks

 

[My_dogs_White]

I've had 24 hours up time (380.57) on 87U, no issues to report!

Thank you Merlin!

 

[GoNz0]

I really don't know if that would be something worth pursuing or not. I guess if someone wanted to take the time to test very single channel on the list to see if by chance the internet starts working again on a broken 2.4 GHz band, it would be good to know.

But I brought this change up more to suggest the possibility that perhaps the changes made in this area somehow managed to screw up the 2.4 GHz internet connection on a large number of non-EU based 68Us and their variants.

That change was the ONLY 2.4 GHz related item listed in the same firmware update that consistently breaks the 2.4 GHz band on a significant number of previously fully functional routers. As I relayed in my experience, this latest FW version broke the 2.4 GHz band's internet connection

Flashing back to the previous version that does not include this minor change to the 2.4 GHz band for EU based routers returns the 2.4 GHz band to full working order on all routers that break under 380.57 and ASUS's own 1031 which is incorporated into this latest version of Merlin.

It just struck me as an interesting coincidence that we see the first 2.4 band change in this version's release notes, and at the exact same time, 2.4 bands start breaking after installing the same piece of firmware.

possibly why mines working ok as the bootloader is region free.

 

[jax]

Congrats on the latest release RMerlin and happy holidays to you and everyone here on the forums!

I wanted to bring everyone up to date on the 2.4 GHz band bug I reported to you last week which prevents any device connected to the 2.4 band on my 68U rev. B1 from sending or receiving data over our internet connection. A few of our devices are unable to connect to the router at all using the 2.4 side, and those that are able to connect display a TX Rate of "1" and an RX Rate of "-" for the duration of that device's connection to the 2.4 GHz side of the 68U B1 as long as either the latest ASUS or your new release version of Merlin firmware is installed on the router. The 5 GHz band is totally unaffected with all devices connected to that band performing normally. Including any device that could not connect to the internet using the 2.4 GHz band.

I contacted ASUS about this problem immediately after a brand new replacement 68U from Amazon was found to demonstrate identical behavior upon the flashing of ASUS factory firmware version "380_1031" posted to the ASUS support site on 2015/12/11.

An ASUS support staff member contacted me via email this past Tuesday and asked me to email them a copy of my settings file that was associated with this issue. I sent them a copy of this settings file immediately and am now awaiting a report from their senior tech manager on the exact cause of the issue and when we can expect an update to whatever software component is found to be responsible for this issue. Since we had a change to both the SDK and the wireless drivers, it could take longer to track down the problem than is typical, but they now have everything they need to easily produce the problem any time they want.

I got the impression from the conversation that they were already aware of this issue, and appeared to be quite pleased when I informed them that my settings file could reproduce the 2.4 band failure on demand as long as 1031 and all associated software components were installed on the test router.

Lastly... I can only confirm this issue with the rev. B1 version of the 68U since this is the only model we have ever had access to. This is the 68U that comes with the 1000 Mhz CPU out of the box.

Cheers.

Just a mention for anyone else who might see this, I had to roll back from RT-AC68U_380.57_0 to RT-AC68U_378.56_2 because of what seems like the mentioned 2.4 band bug.

 

[Giuliano]

Hi to all. I'm an italian user of an AC68U Router rev A2 bought on june 2015 via Amazon. I've the same issue of 2.4 Ghz coming from 378.56_2 to 380.57.
I also tried to change channel between 1 and 13 before to read this thread without solve the problem. The only way has been to come back to 378.56_2.

I also experienced in the last two months to loose ip conection with my pc connected by cable and then other devices connected wireless. The only way to solve this issue is restarting the router. So, i tried Merlin's in the hope to solve but I did not.

 

[tonp]

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.

Running a very stable 378.56_2 on a RT-AC68U from the very beginning of this release.
Without any issues, hickups or whatsoever.
Changing the NAT Acceleration to Disable did not change anything , albeit I had to reboot.
And yes, many thanks to Merlin!

 

[icornish]

I had been alpha testing the 380 release, and had a few hiccups, but the alpha4 release was quite stable, and the 56_2 was very stable.
I took the plunge to upgrade to release version of 380, including a factory reset and re-build all settings, and things were ok for the first 24 hours. Then we lost 2.4G band. Rebooted.
both wifi bands came back, but we then found that devices on the 2.4 band could not see devices on the 5g band (works fine on 56_2 f/w) (No, AP isolation was not enabled). LAN devices could see the items on the Wifi bands.
We then noted that the range on both bands had been cut back. 56_2 could *just* make to the bedroom; alpha4 was quite good in the bedroom; 380 was back to the levels we had on 56_2.
As of now, I have reverted to 56_2 as it is stable, and with all the kids home due to holidays, it easier if I don't break things at the moment...

In summary:-
* range appears to be impaired
* stability of 2.4 wifi band was unreliable
* cross band networking did not work

Device is RT-AC68U 800Mhz model in EU.

 

[GG7]

In summary:-
* range appears to be impaired
* stability of 2.4 wifi band was unreliable
* cross band networking did not work

Device is RT-AC68U 800Mhz model in EU.

Did you also loose internet connectivity with all of your devices that were connected to your 2.4 GHz side?

That for me is the calling card of this problem, especially considering there was/is no getting around the loss of ALL internet access for any device connected to our 2.4 band.

I could see most of them listed via the NETWORK MAP/CLIENTS, and they all had the same signal strengths as they did with 378.56_2, but the TX RATE listed for each and every connected device was the number 1.

This jumped right off the screen at me since it looked so strange to see all these number one's down the entire client list for 2.4 GHz band, one after the other. Then we had a few devices that struggled to reestablish a WI-FI connection with our 2.4 side of the 68U.

One of these devices was my own 2015 Macbook Pro. I normally use the 5G side to take advantage of the 802.11AC speeds, but we have an older MBP here that does not have AC and always uses the 2.4 G side, and that laptop also struggled to connect as long as the 68U was running either 380. firmware. My MBP displayed several pop-up warnings that the network I was trying to connect to was weak and basically not functioning properly.

Selecting the 5G band gave both machines an immediate WI-FI connection to the router and internet performance was great! No change from the 5G performance and behavior seen when running 378.56_2.

I assume that the TX RATE of "1" is directly related to the fact that ALL internet activity between the 2.4 GHz connected devices and router's 2.4 radio is dead in the water.

Flashing the router back to 378.56_2 results in an immediate return to normal functionality. The 2.4 GHz band and all connected devices are back to normal, with speeds and connect times all excellent.

 

[martinr]

....
alpha4 was quite good in the bedroom.....

 

[Zirescu]

I had issues with updating my AC87U, after the manual reboot the wireless didn't come up and also couldn't access it via the LAN. The router would reboot itself after a couple minutes, and then again. I suspect there is something specific to my configuration that the new firmware doesn't like. The only thing that I think might be exotic is that I've got $ signs in my password. I ended up having to do a WPS reset back to factory defaults to be able to access the router again. Loaded back my nvram settings using John's tool and rebooted the router again and couldn't access the router. Ended up doing a factory reset again, reverting back to 378.56_2, and applying my nvram settings again and no issues. I had an issue with the alphas too, but figured it might be just the alpha giving me grief.

Will do some more trouble-shooting this coming week and report back.

Hope everyone has/had a Merry X-mas and a have a prosperous New Year.

Ok, I've tracked down the issue to the Traffic Monitoring settings. It appears that if I enable the custom location option and supply a location on my USB key (reset the data files (or don't for that matter)) and apply the settings the router goes into continuous reboot mode with the WAN LED fast blinking. Doesn't recover until after I reset back to factory defaults. For the meantime I've disabled the logging to the USB key.

 

[GG7]

Is there actually a continuous reboot mode for some purpose? Or do you simply mean that the thing has lost its mind over the glitch in the firmware's instructions to the hardware?

Your CPU heat isn't spiking off the scale during this event is it?

 

[pilotboy72]

Upgraded to 380.57 and performed a factory reset on my RT-AC3200. I see drop outs of the 2.4GHz signal (using WiFi Explorer on Mac) periodically since the upgrade. About 45 seconds after the dropout I get connectivity problems in that I can't initiate a connection to any site. I adjusted the transmit power on the 2.4GHz band and the drop outs seem to be better in that they are less frequent (from about every 3 minutes to more than 10 minutes apart on average).

Has anyone else with the 3200 seen anything similar?

 

[Zirescu]

Is there actually a continuous reboot mode for some purpose? Or do you simply mean that the thing has lost its mind over the glitch in the firmware's instructions to the hardware?

Your CPU heat isn't spiking off the scale during this event is it?

Once the setting is applied you can no longer reach the router (no Wifi, no LAN access), so no means to check the CPU temperature. I'm fairly certain temperature isn't an issue as my typical temp settings on my AC87U are: 2.4 GHz: 35°C - 5 GHz:45°C - CPU:66°C

Might be that the setting isn't getting written to NVRAM correctly but as I always have to reset it back to factory to access the router again I've got no way to check.

 

[GG7]

Ahh! I see what you mean! That is frustrating to have no way to check router status at the time this is all going on.

I agree with you about the heat issue. It would take the CPU at least several minutes to rise to a level that would cause the hardware to reboot over any heat related issue. 66°C is nice and cool too! Mine tends to level off at about 71°C to 73°C with an indoor room temp of around 65°F.

Whatever the cause, I must say that for those that do run into problems running this 380 generation firmware, the problems are quite bizarre and difficult to pin down to the root cause. (In fact, I don't believe anyone has truly found the root cause for any of these problems to date)

I just hope that ASUS is actually working on cleaning all this up right now instead of sitting on their hands!

It has been well over 2 weeks since I first opened my ticket with ASUS support over the 2.4 GHz/internet bug and over a week since I sent them a copy of the settings file they asked me to send them. A file that contains whatever ingredient this firmware needs to kill all internet connections on the 2.4 band just as reliably as clicking an ON/OFF switch!

I wonder if all these issues are related to the same thing? And if that is the case, is the root problem buried so deep within the core functionality of the firmware that they are truly stumped as to how to fix it without breaking a bunch of other stuff in the process? Or even worse... A conclusion that one or more of the new features needs a complete re-write or deletion from the firmware to eliminate the problem (s) ?

I'm seriously starting to wonder.