Asuswrt-Merlin 380.57 is now available

[LexLuthor]

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

Wow, talk about reading comprehension. I give up replying to you and will see if anyone else want to chime in.

 

[ericbergan]

Wow, talk about reading comprehension. I give up replying to you and will see if anyone else want to chime in.

I think eddiez has pretty much covered it. Feel free to not do the reset and see how it works for you, but if there are problems, I'd suggest doing the reset.

 

[SenorClean]

Thanks as always for your efforts Merlin - in case it helps get to the bottom of the 2.4 Ghz issue:

I have a 68u and seem to have the 2.4 issue - often it won't connect at all, and if it does I have no connectivity - can't even ping the router. 5ghz is fine..

Before checking this thread, I played around with a few settings to try to fix it. Changing the 2.4 radio to 'Legacy' mode (ie 802.11b/g) makes it work.

I haven't done a wipe yet - so will try that later when my wife isn't here to complain about breaking the internet :/ otherwise I'll roll back I guess.

 

[bluepoint]

I haven't done a wipe yet - so will try that later when my wife isn't here to complain about breaking the internet :/ otherwise I'll roll back I guess.

Try to enable(auto) "NAT acceleration", when NAT acceleration is disabled, it breaks the 2.4 band.

 

[SenorClean]

Try to enable(auto) "NAT acceleration", when NAT acceleration is disabled, it breaks the 2.4 band.

Thanks - I tried that after reading further through the thread. It turns itself back to disable after reboot (probably because I have traditional QoS on).

I've rolled back for now a few it's all good - I'll experiment with ctf next week when I get a chance.

 

[BobbyFlobby]

On two ac68s, I havent been able to get a decent signal for 2.4 from any firmware after 378.55 which works flawlessly. Have tried complete reset and reboot and disable NAT etc, but seems the only thing that works is going back to 378.55

 

[jerry6]

Wow, talk about reading comprehension. I give up replying to you and will see if anyone else want to chime in.

if you read the faq on the ASUS site you'll read this
""
※Notice: After upgraded the firmware please press the hardware reset button of router over 5~10 seconds to reset the router. ""

Right on this page !!! Scroll down you'll see it for yourself !
http://www.asus.com/support/FAQ/1010600/

 

[chele809]

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.

Well to me.... the first before than anything else...

Sent from my SM-G925T using Tapatalk

 

[chele809]

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...

I'm not investing in a license FOR Merlin... But will Gladly pay for his firmware if I needed to... If he goes another route....

Sent from my SM-G925T using Tapatalk

 

[RogerSC]

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 when the SDK is updated, resulting in a new version of the wireless driver when the firmware is built (and other wireless driver changes may have been made as well), the defaults settings that are hidden from you that the wireless driver uses are very likely to have changed. That means that if you don't reset, there's no telling how the behavior of the new wireless driver will play with the old hidden default settings. If you do a reset to factory defaults, you know that you're starting with the correct defaults for the new driver.

On the other hand, as other posters have said, if you don't want to do a factory default reset, then don't.

 

[akbor]

So, gentlemen, USB3 is definitely not working in Merlin's v. 380.57_0. I tried to flash back the previous v. 378.56_2 and USB3 is working there. After flash I always set the router config to default. Can anyone confirm this bug please?

Regards

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

 

[LexLuthor]

if you read the faq on the ASUS site you'll read this
""
※Notice: After upgraded the firmware please press the hardware reset button of router over 5~10 seconds to reset the router. ""

Right on this page !!! Scroll down you'll see it for yourself !
http://www.asus.com/support/FAQ/1010600/

Take a look at the firmware update page here
http://www.asus.com/us/Networking/R...oduct&utm_medium=referral&utm_campaign=router
(click Windows 10-64 bit, then firmware from above link)
Some of the updates are specifically noted that a reset is suggested. 3.0.0.4.380.1031 is NOT one of those.

Many of you seem to be unable to comprehend what I'm asking, so I'm done, it really doesn't matter. Like it's been said, if it works without the reset, great, if not, do a reset. I just thought it might help me/others understand things better if I heard why rmerlin thinks the sdk+wireless driver update requires a reset and Asus does not.

 

[martinr]

......
. I just thought it might help me/others understand things better if I heard why rmerlin thinks the sdk+wireless driver update requires a reset and Asus does not.

I must admit, I'm now slightly intrigued why Asus didn't specifically note a restore to factory default (RFD) settings after upgrading. My money is on its being an oversight on Asus' part. But even if I didn't understand Merlin's reasons for specifying an RFD, I'd personally never "see what happens if I don't" because Sod's Law would intervene and the router would start to play up after I'd forgotten I'd deliberately disregarded Merlin's instructions (plus I trust Merlin implicitly). And then I'd be posting back here asking for help and wasting people's time.

Anyway, let's hope this sub-thread is now a deceased sub-thread.

Happy new year to all.

 

[jsmiddleton4]

"So, gentlemen, USB3 is definitely not working in Merlin's v. 380.57_0."

Works fine for me.

 

[jsmiddleton4]

"On the other hand, as other posters have said, if you don't want to do a factory default reset, then don't."

That's right. If you want to be absolutely certain you don't have any variables left over from previous FW that MIGHT be causing a problem, do a full NVRAM clearing start from scratch reset and rebuild your configuration.

If you aren't having any issues or don't feel like you need to clear everything out, let it be.

I haven't done a full reset since moving to RMerlin's the last big change. Went from non-alpha, to alpha and now to the non-alpha 380. When I went from RMerlin to Shibby I did full reset before and after moving to Shibby's. Did same when coming back from Shibby's to RMerlin's. Full reset before loading RMerlin's and did so after.

Why Asus recommends one thing and RMerlin another is anyone's guess and near as I can tell irrelevant to whether or not I should for my router in my context do a reset.

This issue comes up over and over again and each time it is the same. Folks over thinking it and hunkering down about their particular point of view.

As MrDoh indicated, do it, don't do it. Its up to you.

If you're having any issues and have not done a full blast your NVRAM, blast any other stuff that might be laying around from previous FW, who cares what Asus or RMerlin recommends? You need to do a full router clearing reset and rebuild your config. I know there are utilities out there to restore a previous config. I'd not use them IF the goal is to eliminate any possible variables from previous FW's to trouble shoot possible FW issues.

 

[kvic]

RFD or not to RFD...seems a new year resolution for lots of people. lol

One nice GUI feature for ASUS or Merlin to add would be not to reboot on changes applied that currently do without users consent. This is so Microsoft way that ASUS UI designers copied without a second thought IMO.

I meant even Windows nowadays will tell users one user action need reboot to be effective and let users choose to reboot immediately or later.

I really think ASUSWRT GUI shall have a similar implementation. After "Apply", either allow users to choose "yes, reboot now" or "no, I'll manually reboot later' or similar prompts alike.

For me then, I can put in all changes from my little settings doc, do one reboot. No more silly wait.

The reboot waiting time is getting longer and longer over the past year to accommodate all the models supported. Getting annoying long! (usually at 60%, it's actually done for RT-AC56U).

(For ppl going to suggest John's NVRAM utility, I'm fully aware of that...)

 

[Ache]

380.57 unlike previous version have bad habit regarding to SIP: it receive UDP answer from the SIP server only if "SIP Passthrough" in the NAT Passthrough is turned ON (default).
I don't need any passthrough since my machine is connected directly to the router and its NAT and I don't use any VPN, so I disable it and it works in all previous firmwares.

 

[jerry6]

fghh

 

[eddiez]

380.57 unlike previous version have bad habit regarding to SIP: it receive UDP answer from the SIP server only if "SIP Passthrough" in the NAT Passthrough is turned ON (default).
I don't need any passthrough since my machine is connected directly to the router and its NAT and I don't use any VPN, so I disable it and it works in all previous firmwares.

It looks like the NAT function is working now, compared to the other previous releases
You would still need NAT I think since you're SIP device is getting an internal IP from the router. Don't really see what you're trying to say here...

 

[Ache]

It looks like the NAT function is working now, compared to the other previous releases
You would still need NAT I think since you're SIP device is getting an internal IP from the router. Don't really see what you're trying to say here...

SIP clients (hardware and software ones) always have a wide set of their own ways to get external IP: STUN servers, UPnP, etc., then telling it via HTTP-like headers , "rport", ICE, etc. along with internal one, so this is not the case. On directly connected device, at least, SIP can work without any special handling, moreover, when ICE is used, it can work via sequence of locally connected machines (I don't know about VPN thing here) and turning "SIP Passthrough" damages proper SIP response from the device in all such cases.