[Beta] Asuswrt-Merlin 384.16 beta (and 384.13_5) are available

[rotareneg]

The traffic monitor spike issue is still present in beta2 on an AC66U_B1.

 

[axaro1]

Asus RT-AX56U 384.16_beta2
First install -> Runner : Enabled.
Enable QoS -> Runner : Disabled (Qos).
Disable Qos -> Runner : Enabled.

After that when i reboot router Runner stays Disabled (no QoS in brackets). I have each time to re enable QoS and then disable QoS to have Runner : Enabled.
Scripts running : Diversion, uiDivStats, Entware packages.

Does the bandwith limiter works on your RT-AX56U with beta 1/2?

 

[S.claus]

Does the bandwith limiter works on your RT-AX56U with beta 1/2?

You realize we are all running the same beta files right ? Download the latest stock Asus firmware and test the limiter if it limits then they fixed it if it doesn’t then they haven’t .

 

[JWoo]

Agree! Complaining is not a solution. Try at least 2 or 3 things to resolve your problem. If it is not solved after a couple attempts, document the problem and share the information.

 

[maxbraketorque]

It isn't really because of the usage lately but this quad9 bug has been there for awhile, it chokes then recover very quickly. Just to make sure try use another DNS server(cloudflare or any) and see if there is change.

Up until a few weeks ago Quad9 has been perfect for me since I started using it perhaps 6-9 months ago. Perhaps in my case the few times I've seen non-resolution is more due to the shift to teleworking.

 

[ech]

The traffic monitor spike issue is still present in beta2 on an AC66U_B1.

FWIW, I'm not seeing the traffic spike on my AC68U, and did see it under beta1. (6 days uptime)

 

[RMerlin]

The traffic monitor spike issue is still present in beta2 on an AC66U_B1.

Beta 2 rstats code is 100% identical to that of 384.15. Make sure you aren't looking at old traffic data that was gathered while running beta 1.

 

[rotareneg]

It was live data, I was looking at the traffic monitor on an Android tablet while uploading a video to Youtube from my desktop. The connection is 50/50M PPPoE and the router had about 2 days of uptime on beta2 at that point. The spike was not recorded on the 24 hour graph. Here's a screenshot I took when it happened:

 

[rotareneg]

Hmm, just noticed that it seems to have happened at or very close to noon. I'll try uploading something tomorrow at the same time to see if I can replicate it.

 

[DonnyJohnny]

A (very early!) sneak peak for those of you interested in building the firmware yourselves;

nice work...
Can we have a new thread for it... for easy search in near future once the script is more mature.

thank you in advance.

 

[TechTinkerer]

@Adamm when are you going to offer it up to testers? Thanks great work on the firmware script

 

[Adamm]

@Adamm when are you going to offer it up to testers? Thanks great work on the firmware script

No set time-frame, I want to make sure everything is polished before release.

 

[Asad Ali]

@Adamm when are you going to offer it up to testers? Thanks great work on the firmware script

It's publicly available on his Github repo, if you're up for the adventure. [emoji16]

 

[Adamm]

It's publicly available on his Github repo, if you're up for the adventure. [emoji16]

I highly suggest against using the script before it is ready which is why I haven't posted the link anywhere, I will not be offering support and core functionality is bound to change which will lead to issues.

 

[Asad Ali]

I highly suggest against using the script before it is ready which is why I haven't posted the link anywhere, I will not be offering support and core functionality is bound to change which will lead to issues.

I agree that's exactly why I didn't post the URL of your repo either. Honestly, firmware compilation is a risky business and those who don't know how to set up a simple build environment manually and need a script to do all the weight lifting shouldn't even try doing that. No offense to your script, it's great for those who know what they're doing.

 

[Phil Outram]

I just saw an update drop with new QoS categories will this be added in beta 3 when the gpl is available?

Even without the latest gpl my AX88U is now identifying this traffic correctly. As an example, Microsoft Teams is now being identified as VOIP where as previously it was under web surfing. I suspect the when AI Protection updates this also updates the traffic clasifications since QOS uses the Trend Micro engine. Interestingly my AI protection updated on the same date that the new official firmware dropped. My Current signature version is:

2.170 Updated : 2020/03/27 02:00

 

[Vexira]

Even without the latest gpl my AX88U is now identifying this traffic correctly. As an example, Microsoft Teams is now being identified as VOIP where as previously it was under web surfing. I suspect the when AI Protection updates this also updates the traffic clasifications since QOS uses the Trend Micro engine. Interestingly my AI protection updated on the same date that the new official firmware dropped. My Current signature version is:

2.170 Updated : 2020/03/27 02:00

That is correct the signatures are tied to each other, the main concern that I have is how the new categories affect the QoS script I and many others are using.

 

[RMerlin]

384.16 Beta 3 (and refreshed 384.13_5) releases are now available.

Changes since beta 2:

ax:

f36914c613 Updated documentation
ed918d6bc0 Bumped to beta 3
9fe91525c9 busybox: disable modutils alias support
de768b3c6a usb: let the scheduler handle CPU affinity for smbd on HND
56a7958ff7 webui: fix field layout for tlsremote setting on ovpn client page
4e6cd15132 openvpn: implement support for verify-x509-name with "subject" or "name-prefix" types ("name" was already supported)
af5c1e32c1 httpd: fix support for USB disks with a single quote in their model name
26a054dbc8 SDK-6750: do not use prebuilt bcm_usb, use the GPL source code to build it ourselves
f3b5e14fbe Revert "rc: only load bcm_usb module after loading HCI drivers"
dbdda187ca dropbear: strip version from ident
fe92a9496e dropbear: fix security notify (backport from mainline)
e488a73eeb dropbear: disable 3des & cbc, tune fastopen options
9203353a35 inadyn: missed part of acef2a0c71f32c64934c7db4102b8a27ce50c7f9
acef2a0c71 inadyn: drop autogenerated stuff for easier updates

This fixes USB enumerating on the RT-AX56U and RT-AX58U, and also fixes SMB sharing performance (up to >100 MB/s from the original 65 MB/s). LAN LED issues when turning the LEDs off and back on will have to be fixed by Asus, the bug is in a closed source function.


mainline:

f36914c613 Updated documentation
ed918d6bc0 Bumped to beta 3
9fe91525c9 busybox: disable modutils alias support
de768b3c6a usb: let the scheduler handle CPU affinity for smbd on HND
6df4f22adc webui: fix field layout for tlsremote setting on ovpn client page
af5c1e32c1 httpd: fix support for USB disks with a single quote in their model name
dbdda187ca dropbear: strip version from ident
fe92a9496e dropbear: fix security notify (backport from mainline)
e488a73eeb dropbear: disable 3des & cbc, tune fastopen options
9203353a35 inadyn: missed part of acef2a0c71f32c64934c7db4102b8a27ce50c7f9
acef2a0c71 inadyn: drop autogenerated stuff for easier updates
80c3c9e57c Merge RT-AC86U SDK + binary blobs from 384_81352

legacy:

a857b188c5 Updated documentation
ab81edbd96 dropbear: strip version from ident
8d85eab280 dropbear: fix security notify (backport from mainline)
2211abd317 dropbear: disable 3des & cbc, tune fastopen options
84f2c243d2 httpd: fix support for USB disks with a single quote in their model name

Still looking for user feedback on AiCloud and ipset for the RT-AX56U and RT-AX58U.

 

[archiel]

I have just taken delivery of an AX58U as a replacement for my AC87U and have several observations on running this with 384.16_beta2. I would be very grateful for any feedback on what is 'normal', what is a result of how I have configured the router and what may be issues with the firmware.

Having previously taken notes / screenshots of the old settings, I booted up the AC58U, did a very basic setup and then installed 384.16_beta2.
I then formatted the JFFS partition and then manually added basic settings (separate SSID for 2.4 & 5), enable WPA2/3, 802.11ax / Wi-Fi 6 mode, re-added various manual addresses into DHCP and reconnected my wifi clients. I have also disabled the Asus DDNS while I wait for it to be removed from my old router and setup one client VPN for a specific device and this seems to be working fine

I have not yet enabled AI Protection or QOS or added a USB card.

The first and most noticeable difference between the old and new routers is the substantial drop in WiFi signal - I predominantly use the 2.4 band (as the construction of the house is not so good for 5). The RSSI signals (2.4) reported in WiFi logs show deterioration of between 10 and 15dBm per device and (in case this was a difference in reporting) this is verified by the signals been noticeable weaker as seen on each device, with some parts of the house now becoming voids. Should I expect such a marked difference between an AC87 and an AX58 and if not what should I check next?

I have also tried reverting to WPA2 and disabling 802.11ax / Wi-Fi 6 mode but neither made any difference.

I have also tried to see if I could disable Protected Management Frames and to set the Extension channel to 'below'. However as soon as I 'Apply', the settings revert to 'capable' and 'above'.

Finally I am trying to understand how to use Wifi Radar - the only APs that are visible are the SSIDs on the router. if I look at the channel statistics I get
Current Channel : 8l
Current Channel BandWidth : 40 MHz
Current Available Capacity : 0%
and
Current Channel : 36
Current Channel BandWidth : 20 MHz
Current Available Capacity : 0
and all the graphs beneath are empty as are all the counters in Advanced Troubleshooting.

I would be very grateful for any assistance in understanding whether the AX58 is just much less powerful, I am setting things up badly or these are software/firmware issues.

Thanks Archie.

 

[Deleted member 22229]

Can't speak for the 2.4 GHz band on my AX58 as i keep it disabled unusable were i live. But the 5 GHz band has a very good signal every bit as good as my AC3100 and very close to my NG R7800. Maybe your drop is due to the AX58U being a 2x2 and your 87U is a 4x4, You are the first to report low signal on the AX58U. I wonder if others are having the issue on 2.4 band.