[Beta 384/NG] Asuswrt-Merlin 384.5 Beta is now available

[Grisu]

As I said I have no problem with telling people to do a reset if something isn’t working, but that’s not what you initially wrote and in fact I’ve seen multiple posts from you where you basically are heavily implying that a reset must be done after every 384 update. This is the first post I’ve seen where you said “possibility a reset will be needed”, which is a much more accurate statement.

Rather than state only people who are “very lucky” won’t need to flash after an update, it would be more accurate to state that a reset isn’t necessary unless you run into a problem.

That’s all I was trying to say and all I will say further on this matter.

Keep in mind 99 of 100 people have no need to do factory reset, but they all will never look at this forum!

Only those with issues will look for help, and they as first step shall make factory reset.

So you ALL are right, those who say not neccessary, for 99% of all customers its correct.
And those who say always, because its correct for almost 100% of people asking for help in the forum.
Nobody says it helps all times, but often and like a power down its the second step to do BEFORE involving others with problems nobody else can even see.

 

[dvohwinkel]

Not unusual. Sometimes a factory reset is necessary.

RMerlin recommends it, especially if there’s odd behavior.

https://www.snbforums.com/threads/faq-nvram-and-factory-default-reset.22822/

Here is my method for the extra cautious and definitely for people with odd problems that others are not seeing..

0) unplug any USB devices connected to your router
1) reset to defaults (yes using the old version of whatever you have on your router)
2) unplug for 10 seconds and power up (power cycle)
3) flash the version you want
4) unplug router for ten seconds (power cycle)
5) reset to defaults
6) unplug router for ten seconds (power cycle)
6.5) Administration -> System -> Format JFFS partition at next boot -> YES -> Apply and Reboot (Thank you @Yo Curo Tu Matas)
7) setup the router the way you want.

I admit it slight over-kill.. but it has never given me problems and is worth the extra effort.

And let me state the obvious.. always upgrade over a wired connection and never over wireless.

 

[joegreat]

I confirm that a 2nd try to update worked on my AC87Us - looks like Quantenna needed the 2nd push (or a power cycle) to work with Beta 1.

I just wanted to give a heads up that my two AC87Us are running fine now for 4 days with the Beta 1 firmware. All my main functions are OK (see footer)...

...expect one issue: My old enemy "kernel: BUG: scheduling while atomic: mtdblock3" is back in town - now with Deluge (as I had it with Transmission in the past) - not sure it's really related to the firmware version, but it's conspicuous to see it right now so often.
I am carefully managing the bandwidth (and disc throughput), but still it comes now every day once or twice (while down- & up-loading at the same time).

 

[DKW]

Asuswrt-Merlin 384.5 beta is now available for all supported models. In addition to new GPL merges, this release focuses on various things that had been waiting on the Todo list for a while. With this release, a lot of work has been done around the OpenVPN implementation in an attempt to simplify it a bit, removing rarely used or flat out broken settings.

The highlight of this release:

• Merged with GPL 384_20648.
• Merged binary blobs from 384_20648 for RT-AC86U, RT-AC68U and RT-AC5300.
• Updated components: OpenVPN (2.4.6), Dropbear (2018.76), OpenSSL (1.0.2o), miniupnpd (20180412), nano (2.9.5).
• Upgraded the RT-AC86U to the same Busybox release (1.25.1) as used by all other models.
• Revised Traditional QoS implementation. Will require extensive testing to validate that it does fix previous issues, and that it doesn't introduce any new one.
• Added a new service-event script, executed before any service call (for example, restart_wireless). Note that this script will block the execution of the event until it returns, so be careful with it.
• Revised OpenVPN server and client options. Please see below for more details on these changes.
• Revised the System Log -> Connections page due to changes made by Asus to httpd. The new implementation removes the ability to resolve hostnames, and info is shown in a sortabled table (click on a header to sort by that field).
• Added ability to resolve hostnames to the Network Tools -> Netstat page.
• Changed Samba behaviour. From now on, enabling master browser and WINS support requires explicitely enabling SMB sharing.
• Changes to the Firmware Upgrade page layout. Beta Firmware channel selector moved to Tools -> Other Settings, where it will now behave more predictably like a standard setting that can be saved to nvram.
• DHCP server no longer broadcast an empty option 252 value (for WPAD).
• Blocking custom scripts (like pre-mount) will now wait a maximum of 120 seconds before returning control, to prevent permanent lockouts.
• Security fixes for dnsmasq (like CVE-2017-15107) were backported from upstream

This is a summary of the changes made to OpenVPN:

Server changes:

• Removed "TLS Reneg time" (rarely used, can manually be set as a custom option)
• Removed "Server Poll" (which didn't work properly), and reimplemented watchdog service as a cron job, hardcoded to 2 mins frequency.
• Removed "Push LAN" and "Redirect Gateway", replaced with new Client Access setting
• Removed Firewall setting (firewall rules are now always created, and the broken External mode was fixed and integrated into the new Client Access setting). You can now use the postconf script to override it.
• Removed option to respond to DNS queries - enabling the option to Push DNS will also handle it
• Added new Client Access setting to select between three types of access: LAN only, WAN only (will block access to the LAN, including the router itself) and LAN + WAN.
  Keys and certificates can now be up to 7999 characters long.

Client changes:

• Reorganized settings into groups
• Removed "Poll Interval" (which didn't work properly), and reimplemented watchdog service as a cron job, with a hardcoded frequency of 2 mins.
• Removed Firewall setting (firewall rules are now always created). You can now use the postconf script to override it.
• Modified behaviour of Connection Retry. Instead of taking a value in seconds that only affected resolution failure, it now takes a number of attempts, and affects connection failures. Resolution failures will now retry for an infinite period of time (the default OpenVPN value).
• Added "refresh" link which can be clicked to re-query the public IP endpoint of the tunnel
• Keys and certificates can now be up to 7999 characters long.

Things that will require particular testing/feedback:

• Traditional QoS. Please confirm whether Cédric's fixes resolved the non-working Traditional QoS.
• OpenVPN: Make sure nothing was broken by the changes, and provide feedback on those changes.
• miniupnpd: confirm that the new version doesn't break things (one thing is known broken at this time - the ability to report the remaining forward time. Issue logged upstream, the remaining time is temporarily hardcoded to always report N/A for now.

Please keep discussions to this specific beta release. Off-topic posts may be moved or deleted, depending on my mood at the time.

Downloads are here.
Changelog is here.

This update destabilized my RT-AC5300 router. I already have to bypass 5Ghz-1 band and force only 2.4 and upper 5Ghz bands only. If anything hits my 5Ghz-1 band, both 2.4Ghz and lower 5Ghz-1 bands start going up and down constantly. With the Beta firmware, now even my current bypass won't keep the 2.4Ghz and 5Ghz bands up. They keep dropping and returning. And the system logs say "Fatal Error" and "Reinitializing Ai" every time they drop and return. Something is off from Beta from the last version, which at least stabilizes without the use of the lower 5Ghz-1 band.

I had to revert back to the stable 384.4_2 version, and my wifi again stabilized.

 

[DonnyJohnny]

This update destabilized my RT-AC5300 router. I already have to bypass 5Ghz-1 band and force only 2.4 and upper 5Ghz bands only. If anything hits my 5Ghz-1 band, both 2.4Ghz and lower 5Ghz-1 bands start going up and down constantly. With the Beta firmware, now even my current bypass won't keep the 2.4Ghz and 5Ghz bands up. They keep dropping and returning. And the system logs say "Fatal Error" and "Reinitializing Ai" every time they drop and return. Something is off from Beta from the last version, which at least stabilizes without the use of the lower 5Ghz-1 band.

I had to revert back to the stable 384.4_2 version, and my wifi again stabilized.

Don’t think there is any update in the wireless Drivers.
Suggest you try redownload the firmware and reflash again with the steps suggested above.
https://www.snbforums.com/threads/b...eta-is-now-available.46352/page-7#post-403010

 

[zadigre]

I may have found one of the source of the unauthorized error message on the ddns page.

on the network map page, system status section, 2.4GHz and 5GHz tab... LAN Mac Address is showing as 00:00:00:00:00:00 in 384.5 beta 1.
when comparing the output of the ifconfig command, all interfaces are showing the correct mac address... but two new interfaces, not present in 384.4_2 (fw1 and fw2 if I remember correctly) are showing the same
00:00:00:00:00:00 mac address.

I'm back on 384.4_2... and LAN Mac Address shown in the GUI is correct... ifconfig output is also correct.

by the way I have both openvpn and IPSec vpn servers enabled if that makes a difference.

Maybe this has something to do with openvpn changes... I don't know.
And no, I didn't do a factory reset yet...

 

[jerry6]

Keep getting 4 lines of this every so often , never had this show before , this on my new AC 3200 , anything to worry about , or need changing ?
May 3 13:15:12 kernel: HTB: quantum of class 10001 is big. Consider r2q change.

 

[TheOldMan]

My RT-AC3200 uptime 5 days, no issues. Must say it's a smooth firmware. System log shows no whines.

 

[archy141]

My RT-AC3200 uptime 5 days, no issues. Must say it's a smooth firmware. System log shows no whines.

For the ac3200 what are the main benifits of going to 384.x over 370 ?
More memory freed ?

 

[TheOldMan]

For the ac3200 what are the main benifits of going to 384.x over 370 ?
More memory freed ?

I noticed less 2.4ghz and 5ghz drops. Better memory management. No hiccups for five days so far. Devices using both wifi bandwidths rarely drop connections. 370 is old firmware, way too old. So is 380. I like to test cutting edge firmware. So if you want to experience robust firmware, 384 is the way to go.

 

[skeal]

Keep getting 4 lines of this every so often , never had this show before , this on my new AC 3200 , anything to worry about , or need changing ?
May 3 13:15:12 kernel: HTB: quantum of class 10001 is big. Consider r2q change.

This means you have a large upload or download bandwidth set in QOS Settings. I get that too. It's harmless it means QOS is working.

 

[dvohwinkel]

For the ac3200 what are the main benifits of going to 384.x over 370 ?
More memory freed ?

The 370 code is essentially end of life and will not be worked on. The 384.x is the new current line that will get security fixes, new features etc.

 

[Treadler]

384.5 beta 1

Otherwise, firmware rock solid, working as advertised for me!

Except for;

Wireless scheduling: broken.
Only works for a couple of days, then gives up.

Router reboot scheduling: broken.
Works only intermittently.

 

[jerry6]

This means you have a large upload or download bandwidth set in QOS Settings. I get that too. It's harmless it means QOS is working.

Thanks , first time it has shown up . I'll ignore

 

[doczenith1]

Only those with issues will look for help, and they as first step shall make factory reset.

I have to disagree with this a little bit. I don't see the harm in asking if anyone else is having the same problem before going all in with a reset. But I do agree that people should be prepared and realize that a reset is the next step if the issue is an isolated problem. For some of use a reset isn't that big of a deal as we have a minimal setup but for others that reset could make for a laborious reconfiguration.

 

[RMerlin]

I may have found one of the source of the unauthorized error message on the ddns page.

on the network map page, system status section, 2.4GHz and 5GHz tab... LAN Mac Address is showing as 00:00:00:00:00:00 in 384.5 beta 1.
when comparing the output of the ifconfig command, all interfaces are showing the correct mac address... but two new interfaces, not present in 384.4_2 (fw1 and fw2 if I remember correctly) are showing the same
00:00:00:00:00:00 mac address.

I'm back on 384.4_2... and LAN Mac Address shown in the GUI is correct... ifconfig output is also correct.

by the way I have both openvpn and IPSec vpn servers enabled if that makes a difference.

Maybe this has something to do with openvpn changes... I don't know.
And no, I didn't do a factory reset yet...

Might possibly be fixed by this, however I haven't looked at it.

Keep getting 4 lines of this every so often , never had this show before , this on my new AC 3200 , anything to worry about , or need changing ?

These messages have been showing up for random people since the very first firmware release 6 years ago. Just ignore them, they are just notification about the QoS values being used.

 

[DKW]

Don’t think there is any update in the wireless Drivers.
Suggest you try redownload the firmware and reflash again with the steps suggested above.
https://www.snbforums.com/threads/b...eta-is-now-available.46352/page-7#post-403010

I use WPS and reset and flashed back to stock firmware to trouble shoot with ASUS (not much help there). And then reflashed with beta and again used WPS to wipe and bring up. Initially seemed stable, but after kids started watching Netflix, 2.4Ghz and lower 5Ghz-1 started going down and up and down and up. Flashed back to 384.4_2 and router is now again stable on 2.4 and upper 5Ghz bands. I have had to invert the 5Ghz bands with the Smart Connect Rules so the 5Ghz-1 only will accept 802.11ac devices (which I don't yet have any of), and anything that floats to 5Ghz, will goto the upper 5Ghz-2 band. As long as I keep everything off the 5Ghz-1 band (lower) and use the 384.4_2 firmware, it appears to be stable. I also have all advanced features enabled and running without issue. But even if all advanced features are disabled, the 5Ghz-1 band (Lower) destabilizes if anything attaches to it.

 

[Xentrk]

And let me state the obvious.. always upgrade over a wired connection and never over wireless.

I felt that way for a long time as DD-WRT was the first non stock firmware I used where using a wired connection for FW upgrades is considered best practice. DD-WRT can be very unforgiving and you can brick the router if upgrading or flashing improperly. For the past year, I have been performing all of my upgrades via WiFi with no issues. Recently, I started performing minor version upgrades remotely over the OpenVPN server connection for several sites I support. But for a new version, I prefer to me onsite so I can power cycle the router. Or, I make arrangements with someone who is onsite to power cycle the router for me after performing the update.

 

[rtn66uftw]

I felt that way for a long time as DD-WRT was the first non stock firmware I used where using a wired connection for FW upgrades is considered best practice. DD-WRT can be very unforgiving and you can brick the router if upgrading or flashing improperly. For the past year, I have been performing all of my upgrades via WiFi with no issues. Recently, I started performing minor version upgrades remotely over the OpenVPN server connection for several sites I support. But for a new version, I prefer to me onsite so I can power cycle the router. Or, I make arrangements with someone who is onsite to power cycle the router for me after performing the update.

+1 I have been upgrading firmware over WiFi for the past year without any problem as well.

 

[elorimer]

DD-WRT can be very unforgiving and you can brick the router if upgrading or flashing improperly.

This reminds me that this is what settled me on the Asus line originally, because I had been able to recover ostensibly bricked 520GCs and a 520GU when a DD-WRT flash went bad. Starting with an N16 things have been even better: I've had maybe 15 Merlin flashes not "take" but the worst outcome has been the older firmware remains in place rather than resorting to the restoration tool. Sometimes I'd try to upgrade wirelessly, sometimes with a drive in, sometimes both, sometimes animal spirits. But I no longer hold my breath for three minutes, or for that matter have to remember exactly how the 30/30/30 works. I've had maybe 200 dirty flashes go fine, and only had to resort to factory defaults 2 or 3 times. Off topic I know.