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

[RMerlin]

or is there something still "experimental" about the ROG UI version?

I don't really test the ROG UI, so I can't guarantee that it's fully working.

 

[shabbs]

Loaded Beta 1 on my GT-AX6000 Router... this baby is so solid... worthy of a pre-release router load.

So far so good - VPN Director good, DNS Director good, IPTV good, devices all reconnected (IOT, Nest, TP-Link etc...), DDNS good.

Will give all the gear a restart after about 15 min and then let it settle.

Cheers to @RMerlin and team. As always, many thanks.

EDIT: FWIW as noted by others here during the alpha testing, I had to remove the deprecated "keysize" parameter from my OpenVPN client config.

Error in log: Mar 21 18:04:45 ovpn-client1[14446]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:43: keysize (2.6.1)

Once removed and saved, config connects properly.

EDIT 2: Reboots all done... RIP uptime... let's GO!

 

[karateca]

i have this message and i dont know why.

Mar 22 00:04:32 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

 

[AntonK]

I don't really test the ROG UI, so I can't guarantee that it's fully working.

“I don't really test the ROG UI, so I can't guarantee that it's fully working.”

Thanks for the response. But you do offer the ROG UI in your firmware distribution package under your name, so if not you, who is responsible for its functionality? Who tests it to see if it’s viable and can be installed & functional on the routers it’s offered to? It's not a question of guarantees, but of common good practice it would seem to me.

 

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

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

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

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.

 

[DJones]

“I don't really test the ROG UI, so I can't guarantee that it's fully working.”

Thanks for the response. But you do offer the ROG UI in your firmware distribution package under your name, so if not you, who is responsible for its functionality? Who tests it to see if it’s viable and can be installed & functional on the routers it’s offered to? It's not a question of guarantees, but of common good practice it would seem to me.

Asus manages the basic functionality if its bug free on Asus Merlin is not guaranteed. Doesn’t matter if it’s under his name he doesn’t guarantee because he doesn’t debug it much. Complain too much he’ll remove the function it’s only there as an experimental UI.

Personally I like the option to have it even if I don’t really like the theme.

 

[AntonK]

Asus manages the basic functionality if its bug free on Asus Merlin is not guaranteed. Doesn’t matter if it’s under his name he doesn’t guarantee because he doesn’t debug it much. Complain too much he’ll remove the function it’s only there as an experimental UI.

Thanks. Not complaining. Just curious.

 

[ASSAD]

I just noticed 2 issues on my GT-AX11000. I couldn't change wireless settings for 5GHz-2, it would just say Applying Settings and do nothing. Tried rebooting but still couldn't change the settings. I had downgrade to 388.1 to be able to change the settings. I reflashed 388.2 Beta 1 to test again and it failed again to change the settings. Just says Applying Settings and just sits there forever.

The 2nd issue was that I enabled DNS Director and the client list is clearing on a reboot. I tried doing the same on a RT-AX58U(388.2 Beta 1 also) and that one is also clearing the list on reboot but I also tested on a RT-AC68 & RT-AC88U on 386.10 and those are not clearing the client list on reboot

Same here i have it to

 

[Spc]

After 1 day 7 hour uptime, i can now confirm RT-AX86U stays at 160MHz and doesn't switch to 80MHz anymore.
36/160 stays

Speedtest, s23 ultra, my fiber speed to ISP is 1gbit/s, 926Mbit/s.

 

[zaquintar]

Hadn't noticed before since I just started using DualWAN but on AXE16000, every time the router reboots, primary WAN fails to get DHCP assignment (using 10G_1) while secondary (2.5G port) negotiates fine. I have to bounce Eth10G_1 and then it will get the DHCP from the modem (both WAN ports get the public IP from modem using bridge mode). This consistently happens when I reboot the router. Not sure if it is an order of operations thing (e.g. 10G_1 receives DHCP binding before it is ready)

Tested a bit more the Dual WAN functionality. Turned primary WAN off, secondary stayed in Hot Standby instead of taking over as active. Then, turned primary WAN back on and router crashed and rebooted. Pretty unstable feature but at least for a real world scenario (if the primary WAN disappears or cable is physically disconnected) the fail over does work. It is just using the knob to shut down the primary WAN via software that breaks it. Would dualWAN be part of the Asus blob?

 

[kernol]

FULLY enjoy being back on Merlinware - and extend my sincere appreciation to @RMerlin for the part he must have played in marshalling Asus to focus on releasing a consistent GPL version across the range of AX routers he supports. Thanks to Asus too for bringing such a solid foundation to the table in a massive upgrade to the 388 platform.

Some of us on RT-AX86U's have had a wobbly time since the rock steady Merlin version 386.5_2 with issues related to closed source components / WiFi drivers and AiMesh. I reverted to 386.5_2 until Asus stock release 3.0.0.4.388.22525 arrived early Feb 2023 and uploaded, reset and rebuilt from scratch both my RT-AX86U's. I could tell right away that this was a solid stable base [maybe not perfect @Tech9 ] for the next Merlin release .

FWIW - On 388.2_b1 I was able to successfully add, as an AiMesh Node using WiFi only, an old DSL-AC68U [it does not have an Ethernet WAN port to cable connect] on its Asus Stock version 386_50117. I no longer have clients dropping off WiFi and [even though I know it is overkill] my 5G 160MHz sticks without dropping to 80MHz. NB Staying as close to default settings on WiFi with only minor tweaks suggested elsewhere is crucial for stability.

 

[RMerlin]

Error in log: Mar 21 18:04:45 ovpn-client1[14446]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:43: keysize (2.6.1)

I wonder why some VPN providers are using that parameter in their config files. That parameter was needed for very old ciphers like BF-CBC, it wasn't doing anything with any modern cipher such as AES-256-GCM that they should have been using for quite a few years now.

But you do offer the ROG UI in your firmware distribution package under your name, so if not you, who is responsible for its functionality?

When I started including it with 388.1, I advised users that it was provided as an experiment. I spent time ensuring that it was working properly at the time and fixed all issues that I discovered then, however I don't have the time to test the whole ROG UI in addition to the regular UI during development of newer releases. It is added to the archive because quite a few users wanted it, with the warning that I may stop supporting it at any time if it became too much trouble to maintain. The non-ROG UI remains the primary UI that I use and maintain.

Who tests it to see if it’s viable and can be installed & functional on the routers it’s offered to?

This is just a webui. The firmware code itself remains identical in both images, so the worst that can happen would be a specific page failing to render properly (and the majority of the pages are identical in both images, it's only a few specific pages that are different, and the CSS that gets applied to all pages).

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.

Try adjusting your Roaming Assistant threshold value. It's what determines when a client can get kicked off a node. But ultimately, the clients are the ones deciding which AP to associate with, a router/AP can't do much beside kick a client off, or provide steering information that some clients may or may not use to decide which AP to connect to.

Yes, 40Mhz and 160Mhz bandwidth but with little interference from neighbors (though 5Ghz more sensitive now necessitating the change from 36 to 40).

Expect your 2.4 GHz clients to get randomly disconnected. 40 MHz on the 2.4 GHz is simply not viable. Interference isn't just from neighbour APs, it will come from a number of other devices within your house. Starting your microwave oven may very well cause 2.4 GHz disconnections every time for example - same radio frequency band.

 

[zaquintar]

Is the Smart Connect Rule page supposed to be somewhat hidden? I can get to it via the link in the Wireless:General page but it doesn't show it's tab under Network Tools

 

[jksmurf]

<snip>
Expect your 2.4 GHz clients to get randomly disconnected. 40 MHz on the 2.4 GHz is simply not viable. Interference isn't just from neighbour APs, it will come from a number of other devices within your house. Starting your microwave oven may very well cause 2.4 GHz disconnections every time for example - same radio frequency band.

Just a quick Q from someone who pretty much uses (and likes) Auto for Wifi, I note that the 2.4GHz default is 20/40. Will this being kicked out at 40MHz result in 2.4GHz devices dropping back to 20Mhz or are they dropped then try to climb back in at 40MHz, rinse and repeat?

 

[RMerlin]

Just a quick Q from someone who pretty much uses (and likes) Auto for Wifi, I note that the 2.4GHz default is 20/40. Will this being kicked out at 40MHz result in 2.4GHz devices dropping back to 20Mhz or are they dropped then try to climb back in at 40MHz, rinse and repeat?

The router drops to 20 MHz, so no client will try to use 40 MHz.

 

[Dedel66]

Is the Smart Connect Rule page supposed to be somewhat hidden? I can get to it via the link in the Wireless:General page but it doesn't show it's tab under Network Tools

You can find it at "Network Tools":

Can´t you? Refresh browser?

 

[Jeffrey Young]

who is responsible for its functionality?

Alpha and Bata testers?

 

[DJones]

ntp server seems to be crashing

Edit: reinstalled ntpmerlin fixed.

 

[dave14305]

ntp server seems to be crashing

View attachment 48742

That would be an Entware or ntpMerlin issue.

 

[DJones]

That would be an Entware or ntpMerlin issue.

Yeah just reinstalled ntpmerlin and that seems to have fixed the issue. Was generating a lot of logs and looked like my temps on the cpu were up (with a fan). Since moving to the beta doing a dirty update it seems to have broken some entware requiring reinstalling applications afterwhich seem to work fine.