Asuswrt-Merlin 380.57 is now available

[martinr]

if working correctly for you w/no apparent issues then dont reset, your option.
if having issues and cant reslove them then reset for troubleshooting .
dev will usually not offer support until u do a reset.
some fw updates require a reset depending on the code/packages being updated and dev will usually state this.

This is what Merlin wrote in post #1 of this topic:

"A factory default reset is required specifically for the RT-AC68U, due to the switch to a new SDK + wireless driver. Some people reported having issues with the 2.4 GHz band with this new SDK- if that's your case, the only solution at this time is to revert "

 

[Yiannis]

Now I am beginning to get VERY annoyed at this latest release waking up my NAS every freaking hour. Is there a setting in Merlin's software to turn off this feature?

That would be a major fix for me as well. If there isn't a turn off switch, maybe if it could be implemented in the future. From the other thread another user pointed out, it was not clear for me if wakening the sleeping devices was intended by Asus or not.

 

[m_listed]

Reset to factory settings and updated the 68U to this new version from 56_2. Things seemed fine at first, but while I was going through putting settings back manually, the router suddenly restarted with the WiFi disabled. No response after reboots and resets, and the router began rebooting itself with no change in status every few minutes; finally put it into recovery mode and flashed the new firmware to it using the ASUS utility. Although recovery claimed to be a success, the router still would not provide WAN access or wireless.

Finally flashed the previous firmware (56_2) using the utility in recovery mode and this time the WiFi came back online... with all my settings from before the crash restored but now on 56_2. It seems like I'll have to hold off on this release.

 

[gffmac]

Reset to factory settings and updated the 68U to this new version from 56_2. Things seemed fine at first, but while I was going through putting settings back manually, the router suddenly restarted with the WiFi disabled. No response after reboots and resets, and the router began rebooting itself with no change in status every few minutes; finally put it into recovery mode and flashed the new firmware to it using the ASUS utility. Although recovery claimed to be a success, the router still would not provide WAN access or wireless.

Finally flashed the previous firmware (56_2) using the utility in recovery mode and this time the WiFi came back online... with all my settings from before the crash restored but now on 56_2. It seems like I'll have to hold off on this release.

Maybe a bad download?

Sent from my HTC One M9 using Tapatalk

 

[LexLuthor]

This is what Merlin wrote in post #1 of this topic:

"A factory default reset is required specifically for the RT-AC68U, due to the switch to a new SDK + wireless driver. Some people reported having issues with the 2.4 GHz band with this new SDK- if that's your case, the only solution at this time is to revert "

Yes, and that makes sense. But, the official asus firmware also has new SDK + wireless driver and i don't see them saying that an nvram reset is required? Why the different recommendations between asus and rmerlin?

 

[fusionstream]

Bug report:
AC5300
- Clients don't appear in View List under Network Map (Under the ALL tab)
- Clients don't appear in any wireless interface section of View List under Network Map
- Ctrl + V doesn't always work
- Clients don't appear correctly in Network Map -> Client Status
- Clients don't appear in System Log -> All the 5GHz interfaces and doesn't appear in 2.4GHz until DHCP is renewed.

 

[akbor]

Hi,

today have updated my RT-AC68U from Merlin v. 378.56_2 to v. 380.57_0. The first impact I was confronted with: my USB-HDD wasn't mounted anymore. Tried to power-cycle the router and to unplug/plug the USB cable with the same result: USB drive doesn't mount. Then, re-plugged the HDD from USB3 to USB2 socket and, suddenly, it does mount on USB2. Has anyone the same problem?

That's could be the relevant part from the syslog:
Jan 1 14:46:15 disk monitor: be idle
Jan 1 14:46:19 rc_service: udhcpc 561:notify_rc start_firewall
Jan 1 14:46:19 dhcp client: bound 94.125.73.76 via 94.125.73.1 during 259200 seconds.
Jan 1 14:46:21 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan 1 14:46:21 kernel: usb 2-1: new high speed USB device using ehci_hcd and address 3
Jan 1 14:46:21 kernel: usb 2-1: device descriptor read/64, error -71
Jan 1 14:46:21 kernel: usb 2-1: device descriptor read/64, error -71
Jan 1 14:46:22 kernel: usb 2-1: new high speed USB device using ehci_hcd and address 4
Jan 1 14:46:22 kernel: usb 2-1: device descriptor read/64, error -71
Jan 1 14:46:22 kernel: usb 2-1: device descriptor read/64, error -71
Jan 1 14:46:22 kernel: usb 2-1: new high speed USB device using ehci_hcd and address 5
Jan 1 14:46:23 kernel: usb 2-1: device not accepting address 5, error -71
Jan 1 14:46:23 kernel: usb 2-1: new high speed USB device using ehci_hcd and address 6
Jan 1 14:46:23 kernel: usb 2-1: device not accepting address 6, error -71
Jan 1 14:46:23 kernel: hub 2-0:1.0: unable to enumerate USB device on port 1
Jan 1 14:46:24 kernel: usb 3-1: new full speed USB device using ohci_hcd and address 2
Jan 1 14:46:24 kernel: usb 3-1: device descriptor read/64, error -62
Jan 1 14:46:24 kernel: usb 3-1: device descriptor read/64, error -62
Jan 1 14:46:24 kernel: usb 3-1: new full speed USB device using ohci_hcd and address 3
Jan 1 14:46:25 kernel: usb 3-1: device descriptor read/64, error -62
Jan 1 14:46:25 kernel: usb 3-1: device descriptor read/64, error -62
Jan 1 14:46:25 kernel: usb 3-1: new full speed USB device using ohci_hcd and address 4
Jan 1 14:46:25 hour monitor: daemon is starting
Jan 1 14:46:25 kernel: usb 3-1: device not accepting address 4, error -62
Jan 1 14:46:26 kernel: usb 3-1: new full speed USB device using ohci_hcd and address 5
Jan 1 14:46:26 kernel: usb 3-1: device not accepting address 5, error -62
Jan 1 14:46:26 kernel: hub 3-0:1.0: unable to enumerate USB device on port 1
Jan 1 14:46:30 crond[458]: time disparity of 221146 minutes detected
Jan 1 14:50:37 kernel: htb: htb qdisc 14: is non-work-conserving?

Regards

 

[chele809]

It's all closed source now so i doubt Merlin could do anything to fix except maybe some huge firmware hack that nobody wants..

Well I do want some " Huge Firmware Hack" because (To Me) the point of using alternative Firmware is to have the router do things the Manufacturer don't alow you to.... "Overclocking, ad-block, OpenDNS, OpenVPN, and better control of the router Overall... But by everything been "Closed Source" nothing can be done ,if merlin don't go his own route. IF NOT WHAT IS THE POINT OF MERLIN SOFTWARE??? If it's gonna chase ASUS 100% than we may as well use stock firmware... Just my point of view and why I'm in the past using Merlins old firmware.....

Sent from my SM-G925T using Tapatalk

 

[rlcronin]

Starting with 378.55 the OpenVPN certs/keys are stored in jffs space and not in NVRAM. I didn't think that a factory reset cleared jffs, although I remember that there was a discussion to maybe change that and have jffs cleared. If you used the save/restore utility, you can run jffs-restore.sh and it should restore your original certs/keys.

D'oh. Good to know. I had this happen as well but fortunately I had a backup elsewhere that I copied/pasted my lost keys from. In the future I'll use jffs-restore.sh.
--
bc

 

[eddiez]

Yes, and that makes sense. But, the official asus firmware also has new SDK + wireless driver and i don't see them saying that an nvram reset is required? Why the different recommendations between asus and rmerlin?

Really? At least have a question that makes any sense...

 

[eddiez]

Well I do want some " Huge Firmware Hack" because (To Me) the point of using alternative Firmware is to have the router do things the Manufacturer don't alow you to.... "Overclocking, ad-block, OpenDNS, OpenVPN, and better control of the router Overall... But by everything been "Closed Source" nothing can be done ,if merlin don't go his own route. IF NOT WHAT IS THE POINT OF MERLIN SOFTWARE??? If it's gonna chase ASUS 100% than we may as well use stock firmware... Just my point of view and why I'm in the past using Merlins old firmware.....

Sent from my SM-G925T using Tapatalk

The more parts are made closed source by ASUS, the less they can be tampered with. So write a note to ASUS, 'cause the're the ones protecting their firmwares. Unless you would like to invest in getting RMerlin a license...

 

[LexLuthor]

Really? At least have a question that makes any sense...

What doesn't make sense exactly? Same base, why does rmerlin suggest wipe and not asus? Is rmerlin just being extra cautious or is there a different specific reason?

 

[L&LD]

Well I do want some " Huge Firmware Hack" because (To Me) the point of using alternative Firmware is to have the router do things the Manufacturer don't alow you to.... "Overclocking, ad-block, OpenDNS, OpenVPN, and better control of the router Overall... But by everything been "Closed Source" nothing can be done ,if merlin don't go his own route. IF NOT WHAT IS THE POINT OF MERLIN SOFTWARE??? If it's gonna chase ASUS 100% than we may as well use stock firmware... Just my point of view and why I'm in the past using Merlins old firmware.....

Sent from my SM-G925T using Tapatalk

To me, the reason to use RMerlin firmware on the supported Asus routers is the additional functionality he provides and more importantly the bug fixes he implements over Asus' own code. The latter being more important than the first for most of my customers.

 

[eddiez]

What doesn't make sense exactly? Same base, why does rmerlin suggest wipe and not asus? Is rmerlin just being extra cautious or is there a different specific reason?

If you read the thread you would know the answer to this (the RMerlin side anyway).
And asking a question like this is an unanswerable question. RMerlin cannot answer for ASUS, can he? The only one to answer is ASUS and you're not addressing them (they are not on this board offically).

 

[connorm]

@RMerlin you mention RT-AC68U C1 Support?

do you have one of these?

does it have BCM43602?

when will asus be selling this

so far still A2/B1 seem to be everywhere havnt heard of anyone picking up C1 yet

 

[jsmiddleton4]

"Well I do want some " Huge Firmware Hack""

Then you want a Tomato variant like Shibby's. Or if you care to mess with all the variables and learning curve DD-WRT.

"C1: when will asus be selling this"

RMerlin said some time in 2016.

 

[LexLuthor]

If you read the thread you would know the answer to this (the RMerlin side anyway).
And asking a question like this is an unanswerable question. RMerlin cannot answer for ASUS, can he? The only one to answer is ASUS and you're not addressing them (they are not on this board offically).

Wow, you are really helpful. Am just curious why rmerlin recommends a wipe and Asus doesn't.

 

[eddiez]

Wow, you are really helpful. Am just curious why rmerlin recommends a wipe and Asus doesn't.

It's still a dumb question. But then again, you haven't read the thread.

 

[LexLuthor]

It's still a dumb question. But then again, you haven't read the thread.

I've read the thread. RMerlin suggest a wipe "due to the switch to a new SDK + wireless driver". I don't at all think it's a dumb question to ask why RMerlin thinks a wipe is necessary, but Asus apparently doesn't. Maybe you can just let someone else answer at this point rather than tell me I'm not reading the thread again.

 

[eddiez]

I've read the thread. RMerlin suggest a wipe "due to the switch to a new SDK + wireless driver". I don't at all think it's a dumb question to ask why RMerlin thinks a wipe is necessary, but Asus apparently doesn't. Maybe you can just let someone else answer at this point rather than tell me I'm not reading the thread again.

Because remnants of the old driver/sdk are still resident in NVRAM after new firmware update. Is all there in the thread.... [sigh]