Beta Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models

[snah001]

Running Beta 1 for 48+ hrs and so far no problems or weird things detected.

 

[ryosuke]

hmmm.. still nothing for XT12?

 

[bbunge]

I don't know about the tablet but a lot of TCL/Roku tvs do not support DFS channels. The newest ones might, but I'm not sure. I had the same problem and looked it up and my tv doesn't support those channels so it couldn't find the 5ghz network.

The issue is Roku uses a WIFI remote that does not have built in RADAR detection and thus legally can't use DFS channels.

 

[jb1187]

Still getting random reboots on AX11000 with 388.2B, but my AX88U running 388.2B that is connected as an AP is running smoothly. Nothing in the AX11000 logs prior to reboot stands out to me:

Mar 23 01:56:14 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind AC:AE:19:AA:D3:65, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-57
Mar 23 01:56:14 hostapd: eth7: STA ac:ae:19:aa:d3:65 IEEE 802.11: disassociated
Mar 23 01:56:14 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind AC:AE:19:AA:D3:65, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-57
Mar 23 01:56:14 hostapd: eth7: STA ac:ae:19:aa:d3:65 IEEE 802.11: disassociated
Mar 23 01:56:20 wlceventd: wlceventd_proc_event(511): eth7: Disassoc AC:AE:19:AA:D3:65, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 23 01:56:20 hostapd: eth7: STA ac:ae:19:aa:d3:65 IEEE 802.11: disassociated
Mar 23 01:56:33 wlceventd: wlceventd_proc_event(530): eth7: Auth AC:AE:19:AA:D3:65, status: Successful (0), rssi:0
Mar 23 01:56:33 hostapd: eth7: STA ac:ae:19:aa:d3:65 IEEE 802.11: associated
Mar 23 01:56:33 wlceventd: wlceventd_proc_event(559): eth7: Assoc AC:AE:19:AA:D3:65, status: Successful (0), rssi:-55
Mar 23 01:56:33 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Mar 23 01:56:33 hostapd: eth7: STA ac:ae:19:aa:d3:65 RADIUS: starting accounting session 5340A907B4BB42F8
Mar 23 01:56:33 hostapd: eth7: STA ac:ae:19:aa:d3:65 WPA: pairwise key handshake completed (RSN)
Mar 23 01:56:34 dnsmasq-dhcp[1786]: DHCPREQUEST(br0) 192.168.9.254 ac:ae:19:aa:d3:65
Mar 23 01:56:34 dnsmasq-dhcp[1786]: DHCPACK(br0) 192.168.9.254 ac:ae:19:aa:d3:65 RokuStreamingStick
May  5 00:05:08 syslogd started: BusyBox v1.25.1
May  5 00:05:08 kernel: klogd started: BusyBox v1.25.1 (2023-03-20 12:26:57 EDT)
May  5 00:05:08 kernel: Booting Linux on physical CPU 0x0
May  5 00:05:08 kernel: Linux version 4.1.51 (merlin@ubuntu-dev) (gcc version 5.5.0 (Buildroot 2017.11.1) ) #2 SMP PREEMPT Mon Mar 20 12:37:48 EDT 2023
May  5 00:05:08 kernel: CPU: AArch64 Processor [420f1000] revision 0
May  5 00:05:08 kernel: Detected VIPT I-cache on CPU0
May  5 00:05:08 kernel: alternatives: enabling workaround for ARM erratum 845719
May  5 00:05:08 kernel: On node 0 totalpages: 240128
May  5 00:05:08 kernel:   DMA zone: 3283 pages used for memmap
May  5 00:05:08 kernel:   DMA zone: 0 pages reserved
May  5 00:05:08 kernel:   DMA zone: 240128 pages, LIFO batch:31

 

[JGrana]

Running 388.2B on an AX88U Pro. 2 things to report so far:

1 Got a few dnsmasq Tainted errors yesterday. So far today, none

admin@RT-AX88U_Pro-0BD8:/tmp# grep ainted syslog.log*
syslog.log:Mar 22 16:01:04 kernel: CPU: 0 PID: 16804 Comm: dnsmasq Tainted: P O 4.19.183 #1
syslog.log-1:Mar 22 07:16:22 kernel: CPU: 0 PID: 23951 Comm: dnsmasq Tainted: P O 4.19.183 #1
syslog.log-1:Mar 22 07:16:43 kernel: CPU: 1 PID: 1901 Comm: dnsmasq Tainted: P O 4.19.183 #1
syslog.log-1:Mar 22 07:17:14 kernel: CPU: 2 PID: 2625 Comm: dnsmasq Tainted: P O 4.19.183 #1
admin@RT-AX88U_Pro-0BD8:/tmp#

2) I removed a USB 3.0 SSD drive from my older AX88U. Plugged into the AX88U Pro and it was not recognized. Tried a few unplug-plugs and would still not mount the drive. Tried it on an AX58U and it mounted fine. For now I am using an WD USB hard drive - mostly for Entware and Unbound.

 

[forzic]

sorry not for tuf ax6000??

 

[Deleted member 77025]

I use ExpressVPN and have had those configs in place for quite some time.

I re-downloaded a config file just now to see if a more recent version has removed them, but no, it's still in there - maybe due to the AES-256-CBC cypher?

View attachment 48772

Interesting.

Some Providers are using CBC for fallback option if 256 or GCM not working.
2.6.1. has also some changes again and older configs wont work with it i think.

hand-window 120
inactive 604800
mute-replay-warnings
persist-remote-ip
ping 5
ping-restart 120
redirect-gateway def1
remote-random
resolv-retry 60
route-delay 2
route-method exe
script-security 2
tls-cipher TLS_CHACHA20_POLY1305_SHA256:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS_AES_256_GCM_SHA384:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
data-ciphers AES-128-GCM
remote-cert-tls server

 

[Samuel_1975]

I don't know what it is in the system log and yes I don't understand such information at all, I didn't have this in my previous version okay yes installed before the beta version, otherwise I'm glad that a test version came out so man can join and test it yourself, have a good evening

 

[Apul]

I've had the UI lock-up a couple of times now.
After a while it restarts and there's the following lines in the log...

Mar 23 09:40:49 HTTPD: waitting 10 minitues and restart
Mar 23 09:40:49 rc_service: httpd 4107:notify_rc restart_httpd
Mar 23 09:40:49 custom_script: Running /jffs/scripts/service-event (args: restart httpd)
Mar 23 09:40:49 RT-AX86S: start https:8443
Mar 23 09:40:49 RT-AX86S: start httpd:80
Mar 23 09:40:49 httpd: Succeed to init SSL certificate...80
Mar 23 09:40:49 httpd: Succeed to init SSL certificate...8443

I had the same. It's not stable on my RT-AX86s I reverted to 386.5._2

 

[TheOldMan]

I've been having trouble trying to compile the latest 388.2b1 firmware when it broke after the 388.1 successful compile. The issue I'm having is this....
calc_nvram.c:4:10: fatal error: defaults_nv.h: No such file or directory
4 | #include "defaults_nv.h"
Am I missing some files after a git pull?
Anyone having same issues?

 

[RMerlin]

I've been having trouble trying to compile the latest 388.2b1 firmware when it broke after the 388.1 successful compile. The issue I'm having is this....
calc_nvram.c:4:10: fatal error: defaults_nv.h: No such file or directory
4 | #include "defaults_nv.h"
Am I missing some files after a git pull?
Anyone having same issues?

That file is generated by the python script within the calc_nvram directory. Make sure your Python install is working.

 

[aex.perez]

While this release, 388.2B1 is and the GPL it's based on is much better than the initial release of 388.1 specifically with regard to WiFi some slight issues remain, and almost exclusively with 5Ghz.

Devices bouncing between mesh nodes, i.e a Android Tablet (on 5Ghz) in one room, not 10ft away from a AX86 node, randomly switches to the other AX86 Node at the back of the house 50ft away. Same with some Nest cams/thermostats (all on 5Ghz). While the binding to a specific node of a device is mostly correct, and respected on 2.4Ghz, under 5Ghz its ignored unless I cycle the device's WiFi forcing the reconnect. I bind a device to the nearest node in the same room to try and keep things stable. If the devices come up on the wrong node, for 2.4Ghz based devices I can unbind/rebind or wait a few minutes to an hour and they'lll move. Not so with 5Ghz based devices short of cycling the WiFi it doesn't move, even overnight.

Under the 386.8/386.7_2 my 5Ghz was solid on 36/160, on 388.2B1 it doesn't take much for the radio to change to 149/80. To it's credit it does change back to 40/160 - found someone else was 36/80 using the newly introduced Site Survey, hence the change to 40 so it's much more consistent now and staying with 160Mhz for hours on end.

5Ghz devices do still change to another node randomly, from my perception. I say randomly because I don't have the ability to see what's happenning with the radios or whether some interference on the 5Ghz band forced the device to move to the farther node in real time. In the worse case, a 5Ghz device moves to the router on the other side on the house, think of a triangle with router and nodes in the 3 corners. Whether the 5Ghz is more sensitive to noise/interference or something else causes it I can't tell but it sure feels like its more sensitive to the environmentals.

Still, so much better than the initial 388.1, but similar issues with the AX88/AX86, just significantly less often. The mitigation by staying on a fixed channel where I used to have Auto for both radios is probably helping here. So not reverting back this time, but do need to start everything from scratch just to be sure something didn't carry over from all the prior 388.1 alpha/beta/final releases then back to 386 before jumping to 3882b.

A full HW reset of all three, starting from scratch, re-establishing the mesh, re-configuring, adding the scripts back in and letting it run for a few days to see if the issues, though infrequent, still happen. The Smartconnect rule is operating a little wacky as well as, some dual band devices stay on 2.4Ghz never moving to 5Ghz as they did under 386.8/386.7_2 using the same rule, probably need to tweak that a bit.

Screenshots from inSSIDer running on a laptop nearest to the router. SSID2 is for 2.4Ghz devices, IoT and 2.4Ghz ax Tablets. SSID5 is for dual band devices I want to fix to 5Ghz - mostly IOT, Amazon Echo and the like (which resulted in cutting down on all the disassociations in the log, though still get them for some roaming devices as they move about using SmartConnect enabled SSID). SSID is for roaming devices that would better leverage SmartConnect. Then SSID_Guest is for, just that and just for 5Ghz. Note 802.11b disabled at the router and via NVram at the nodes.

View attachment 48729

The slower rates for 2.4Ghz are the AX86 nodes's vs the AX88 router
View attachment 48730

View attachment 48731

Yes, 40Mhz and 160Mhz bandwidth but with little interference from neighbors (though 5Ghz more sensitive now necessitating the change from 36 to 40).
The 2.4Ghz/ax based tablets monitoring the 5Ghz Nest cams appreciate the 40Mhz bandwidth...

View attachment 48732

I can't point to any hard facts from the logs or other metrics other than me observing and reacting to device moves or channel/bandwidth changes and trying to set things stratight again. Where under 388.1 it was constantly happenning, making WiFi completely unstable. It happens once or twice a day with individual devices, specifically those on 5Ghz regardles of SSID under 388.2b, noticeable with the cameras but manageable and not really impacting other 5Ghz devices that would demand any immediate mitigation on my part.

Your results may vary, another reason to start from scratch to level the playing fleld as much as I can.

A quick update since I've spent few days offline rebuilding my PC and all the apps after Windows 10 failed in the most spectacular way, requiring a complete reinstall.

@RMerlin, I turned on the Roaming Assistant (without seeing your post) and set it to to the same -rssi value to disconnect client as the sta selection policy in SmartConnect - now it's working like it did in 386.8 and 7-2. I have had roaming assistant on/off and have messed with the SmartConnect rule due to some of the instability with 388.1 so I suspect this is my doing as to why the devices weren't binding to the closet/strongest signal and potentialy bouncing around due to conflicts between both rules/policies. Will let it run too see if its behavior improves, I suspect it will.

With reguard to the 40Mhz on 2.4Ghz, got to share my that my two WiFi6 2.4Ghz only tablets that monitor the live feeds from the Nest Cams have not dropped or changed to 20Mhz. Call it luck, a fluke but its been and continues to be rock solid. With regard to 160Mhz its also been rock solid, and if I do get the rare Police Chopper buzzing by, it drops to 80Mhz and after the interference is gone shoots right back up again.

Got a problem with the WAN interface, but it doesn't impact wired clients. Just WiFi and SpeedTests at the router, and it only corrects with a reboot (tried restart of modem and SCMerlin WAN restart). Once rebooted, back to normal. Got to do some more analysis / correlation / log gathering before throwing this into the mix though...

 

[aex.perez]

I have to agree that there is something not quite right with this router combination. My experience is that 2.4Ghz IoT devices have been more problematic, and I use a lot of TP-Link Tapo energy monitoring smart plugs which very quickly highlight problems for me.

I have pretty much narrowed my issues down to having Protected Management Frames enabled. On 388.1 I had to set this to disabled and then Authentication Method to WPA/WPA2-Personal to get the devices to happily use the RT-AX86U nodes - if not they would stick on the RT-AX88U main router or bounce around if I tried to bind them. Disabling AX mode entirely gave me very stable connectivity and saw better throughput on other 2.4Ghz devices such as Ring cameras and doorbells.

On 388.2_beta1 now I have found that I can re-enable AX mode and use WP2-Personal as my authentication method and my IoT devices are happily connecting to the RT-AX86Us.

I have become suspicious that the nodes are not getting correctly configured from main router as swapping to one of the RT-AX86Us as a main router on 388.1 showed that the main router is preferred whether it is an 86U or an 88U, it's AiMesh nodes that are not. I also see that InSSIDer reports configuration mismatches between the main router and nodes, and that I have different 2.4Ghz basic rate speeds available.


Can you tell me how do do this at the nodes?

nvram variable wl0_rateset=default/ofdm

default=802.11b enabled ofdm=802.11b disabled (different setting for the check box on/off but you can't get there on a node anyway, and it's just for looks)

SSH into the node:
nvram set wl0_rateset=ofdm
nvram commit
reboot

Done!

 

[Damit1]

It is 2 days now that my router runs, no issues reported.
Ax88u*2 and ax56u.
Hopefully the support this one will continue, my Purchase Preference for ASUS models are strictly models that @RMerlin supoort them.

Should we raise a petition to longer live the GPL support for the low-end models? Haha

 

[Mutzli]

My routers are up for 3 days with the beta. The routers are working the best they have ever been. WiFi is totally stable, the 5GB 160MHz is rock solid. Haven't had a drop down to 80MHz since updating.

 

[AntonK]

With Beta 1 installed with the ROG UI, would moving from the ROG UI to RMerlin's UI pose any special reconfiguration recommendations?

Thanks.

 

[ColinTaylor]

@RMerlin Did you see the IPv6 DoS Protection bug reported in this thread.

firewall-start generates this line when DoS protection is enabled and Logged packets type = None:

-A ICMP_V6 -p ipv6-icmp --icmpv6-type 128 -m limit --limit 1/s -j RETURN

I think it should really be this:

-A ICMP_V6 -p ipv6-icmp --icmpv6-type 128 -m limit --limit 1/s -j ACCEPT

 

[bigpcjunky]

The issue is Roku uses a WIFI remote that does not have built in RADAR detection and thus legally can't use DFS channels.

Thanks, it looks like the model of the Fire HD10(2019) that I have also doesn't support DFS channels. I thought I saw my router on channel 36 and then it auto switched to 100 or another DFS channel so my network 'disappeared' on the Roku. IDK, maybe I got my router in a weird state testing out different versions of firmware.

I've seen my router auto switch channels from 160MHz width to 80MHz, but I've never seen it auto switch from 80MHz to 160MHz width until this build.

 

[shabbs]

With Beta 1 installed with the ROG UI, would moving from the ROG UI to RMerlin's UI pose any special reconfiguration recommendations?

Thanks.

You will need to install the non-ROG version, then do 42 factory resets in a row to ensure it's clear... unplug it for 8 hours to clear any residual config memory from the capacitors, then power up and config manually..... NAH JUST KIDDING MAN... should be able to just dirty slap that on and then give it the old reboot after 15.

 

[AntonK]

You will need to install the non-ROG version, then do 42 factory resets in a row to ensure it's clear... unplug it for 8 hours to clear any residual config memory from the capacitors, then power up and config manually..... NAH JUST KIDDING MAN... should be able to just dirty slap that on and then give it the old reboot after 15.

Hahaha! Thanks!