[Beta] Asuswrt-Merlin 384.8 beta is now available

[RMerlin]

Asuswrt-Merlin 384.8 Beta is now available. As we bid farewell to the RT-AC56U (now officially EOL by Asus), we also welcome a newcomer, the RT-AX88U. The RT-AC87U and RT-AC3200 are not supported by this release (no updated binary blobs from Asus for these two models).

EDIT: (22-Nov) - Beta 2 is now available. Changes since Beta 1:

04eef3934 Updated documentation
1af545344 HNDAX: merge with GPL 384_4736
7b149555c HNDAX: Merge RT-AX88U binary blobs from 384_4736
e6e3e19d8 openssl: updated to 1.0.2q
25159e362 webui: fix FAQ link on Adaptive QoS Bandwidth Monitor page
5b4838b31 webui: clarify fields for tunnelbroker DDNS configuration
3f1a1e2a2 httpd: fix certificate storage location
2a2302e5e kernel: add the TEE Netfilter target
e3c232790 kernel41-ax: add the TEE netfilter target
66985d615 kernel41-ax: sync config options with 4.1.27 (HND AC)
59e3a6704 Updated documentation
d4a1ba661 Bumped revision to beta 2

The highlights of the changes:

• Added support for the RT-AX88U. Feature support should be fairly similar to the RT-AC86U (which shares the same Broadcom HND platform), including the same limitations (no IPTraffic support for example). The RT-AX88U release is built from a slightly different codebase, so there might be some slight differences between that model and other models, until Asus eventually merges that model into the same general code branch as other models.
• Removed support for the RT-AC56U. That model is now EOL by Asus, meaning they will no longer be releasing firmware updates (and therefore, no updated precompiled binary components, making it impossible for me to compile new releases).
• Merged with GPL 384_32799 (384_4730 for the RT-AX88U).
• Added LZ4-V2 support to OpenVPN
• Added CleanBrowsing service to DNSFilter
• HTTP (non-SSL) LAN port can now be changed from the default port 80
• Updated components: dnsmasq (2.80-7-g24b8760), nettle (3.4), net-snmp (5.8).
• Removed watchdog from OpenVPN clients, as it would conflict with some more advanced configurations.
• The FTP server can now reuse the SSL certificate used by your webui when enabling TLS. This includes Let's Encrypt.
• SSL cipher suites were hardened/tightened a bit for the webui
• Enhancements to the Wireless Log page, more details can now be provided on a separate popup.
• httpd SSL certs were moved from /jffs/ssl/ to /jffs/.cert/ to be in line with Asus's own firmware.
• Fixed a bug in curl causing some applications to crash on non-HND models. This fixes IFTTT and WTFast (which has been re-enabled, however remains untested)
• Fixed UPNP refusing to forward ports if your WAN IP was a non-public one. This was caused by a change by the miniupnpd author. This change has been reverted in Asuswrt-Merlin.
• Fixed dnsmasq and routing issues when running in non-router mode
• OpenVPN clients will no longer have their download speed limited by the QoS upload limit when in Adaptive QoS mode.

Please review the changelog for the complete list of changes.


Things in need of particular testing:

• Everything in general about the RT-AX88U. Note that any wireless issue would be completely outside of my control, so no need to report about these.
• Things related to the webui's SSL support. Existing key/certs should be automatically migrated to the new location on first boot, but reverting back to an older firmware will require you to manually copy them back to /jffs/ssl/ .
• WTFast on the AC88U/AC3100/AC5300. While it no longer crashes, I am unable to log in with my old free account. Unsure if the issue is on their end, Asus's end, or a compatibility issue with Asuswrt-Merlin.

Please keep discussions in this thread to this specific release. Off-topic posts will be ignored or removed, depending on my mood at the time.

Downloads are here.
Changelog is here.

 

[RMerlin]

Reserved post.

 

[scjr]

Smooth update over alpha 3. Thank you, Eric!

 

[skeal]

Are the changes to QOS for the next build @RMerlin ?

Edit: Sorry off topic.

 

[JSinFCVA]

Smooth upgrade from 384.7_2. Looks good so far for basic functionality. No issues. yet.

 

[RMerlin]

Are the changes to QOS for the next build @RMerlin ?

Edit: Sorry off topic.

They're in this one, I just forgot to add them to the Changelog. These were missing from the included changelog (they were in a separate version I had):

- CHANGED: Updated CA bundle to October 17th 2018 version.
- FIXED: OpenVPN client download was capped by Adaptive QOS
          upload limit (fix devised by FreshJR)

 

[octopus]

Updated smooth and working fine.
Uptime 0 days 0 hours 31 minute(s) 43 seconds

 

[jsbeddow]

They're in this one, I just forgot to add them to the Changelog.

Hmm...what QOS changes were made? Default built-in version now emulating the @FreshJR scripting?

 

[RMerlin]

Hmm...what QOS changes were made? Default built-in version now emulating the @FreshJR scripting?

No, just that OpenVPN clients download will no longer be limited by the Adaptive QoS upload speed limit.

 

[skeal]

No, just that OpenVPN clients download will no longer be limited by the Adaptive QoS upload speed limit.

Classification of traffic is way better and no need for FreshJR special instruction iptable entry for vpn client. So far anyway!

 

[skeal]

I stream video over my OVPN and it used to be registered as video but in the upload stats. Now without any mods it is being categorized as video download. Booyeah!

 

[PDinDetroit]

On RT-AC86U with 384.8_beta1 using FireFox 63.0.3.

May  5 01:05:07 kernel: nand: Could not find valid ONFI parameter page; aborting
May  5 01:05:07 kernel: nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xda
May  5 01:05:07 kernel: nand: Macronix NAND 256MiB 3,3V 8-bit
May  5 01:05:07 kernel: nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
May  5 01:05:07 kernel: bcm63xx_nand ff801800.nand: Adjust timing_1 to 0x65324458 timing_2 to 0x80040e54
May  5 01:05:07 kernel: bcm63xx_nand ff801800.nand: detected 256MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4
May  5 01:05:07 kernel: Bad block table found at page 131008, version 0x01
May  5 01:05:07 kernel: Bad block table found at page 130944, version 0x01
May  5 01:05:07 kernel: nand_read_bbt: bad block at 0x0000098a0000
May  5 01:05:07 kernel: nand_read_bbt: bad block at 0x00000c000000
May  5 01:05:07 kernel: nand_read_bbt: bad block at 0x00000e220000

Any concerns?

Also, does this mean that HW Acceleration is not working for this model?

May  5 01:05:07 kernel: ^[[0;33;45mBroadcom Packet Flow Cache HW acceleration disabled.^[[0m
May  5 01:05:07 kernel: Disabled Runner binding to Flow Cache

 

[Sanna1967]

does this mean that HW Acceleration is not working for this model?

Working here
Reboot and look in the Tool section if the runner and the flow are still disabled, dont click on adaptive qos tab before, it will disable Runner automaticly

 

[skeal]

Get! Out!

Thanks @FreshJR and @RMerlin !!

 

[PDinDetroit]

Working here
Reboot and look in the Tool section if the runner and the flow are still disabled, dont click on adaptive qos tab before, it will disable Runner automaticly

Runner is disabled after reboot (Disabled (QoS)), but Flow Cache is enabled.

I have adaptive qos configured due to work concerns (Skype for Business). I may go to higher upload speed if possible...

 

[skeal]

A little further testing with the new QOS fix. If you are a FreshJR QOS user, then you will want to remove the vpn client download rule, and keep the upload rule as the fix does nothing for overhead traffic, coming from the vpn download stream. So it's a half fix, sorry guys.

 

[Marin]

Working good so far. Thank you @RMerlin!

One question....what is new with LZ4-V2? How does it compare with other levels of compression?

 

[sfx2000]

Get! Out!

Thanks @FreshJR and @RMerlin !!

Fun stuff...

 

[sfx2000]

One question....what is new with LZ4-V2? How does it compare with other levels of compression?

Bit of discussion on another forum regarding LZ4 - LZ4 looks good on paper, but it's a bit complicated there...

 

[RMerlin]

Working good so far. Thank you @RMerlin!

One question....what is new with LZ4-V2? How does it compare with other levels of compression?

It's pretty much the same level of compression, just that uses more efficient structures, reducing overhead slightly. It's a poorly documented feature in OpenVPN 2.4.

Personally I recommend not using compression with OpenVPN anyway, as most network traffic doesn't compress too well these days (since it's already encrypted).