Beta Asuswrt-Merlin 388.1 Beta is available for select models

[RMerlin]

Been a while since we've seen a Beta 4 in a program.

The last-minute IPv6 firewall issue made it necessary, as otherwise I was ready to release 388.1 final this weekend. I needed to ensure it didn't cause any new issue, hence the extended beta cycle.

 

[Treadler]

The last-minute IPv6 firewall issue made it necessary, as otherwise I was ready to release 388.1 final this weekend. I needed to ensure it didn't cause any new issue, hence the extended beta cycle.

The firewall issue I was seeing looks to be fixed.

 

[Unisoft]

What's the WiFi performance on 5G with stock Asus firmware?

Not tried latest stock from Asus, after manually entering details for Merlin to be sure everything was fresh, don't really want anything from stock to mess up any config tables so I have to input again when going back to Merlin as just done this.

I tried this Enable WMM APSD = Disable and it's made it much better - early days in monitoring. I had this Enabled on previous firmware versions, which if this setting does cure it, makes me think it may not have been working at all before and now Asus/Broadcom have made it work, or work as intended, and hence the issue with this firmware as the Cable company IPTV stream box doesn't like it. Everything else though was fine with ithis setting enabled on this firmware.

 

[JohnNerd]

For the first time in over a years time my Synology NAS suddenly went into hibernation. I'm on 6/7 hour setting for hibernation. Running Beta 3 when this happened. Could it be a code change? "Ping" change? Thank you for your outstanding work as always Merlin. Highly appreciated.

 

[geobernd]

Beta 4 is working stable for me (installed about 24 hours ago) but I am seeing a couple of new log messages I have never seen before:

Nov 30 20:13:01 kernel: bcm63xx_nand ff801800.nand: unaligned buffer: ffffffc02a00f67f
Nov 30 20:44:44 kernel: bcm63xx_nand ff801800.nand: unaligned buffer: ffffffc02a00f36f
Nov 30 21:48:45 kernel: bcm63xx_nand ff801800.nand: unaligned buffer: ffffffc02a00f40b
Nov 30 22:45:06 kernel: bcm63xx_nand ff801800.nand: unaligned buffer: ffffffc02a00f683
Dec  1 03:16:13 kernel: bcm63xx_nand ff801800.nand: unaligned buffer: ffffffc02a00f7c3
Dec  1 05:10:36 kernel: bcm63xx_nand ff801800.nand: unaligned buffer: ffffffc02a00f767

Not sure if that is something to worry about or some other random stuff

 

[capncybo]

... I tried this Enable WMM APSD = Disable and it's made it much better - early days in monitoring. I had this Enabled on previous firmware versions, which if this setting does cure it, makes me think it may not have been working at all before and now Asus/Broadcom have made it work, or work as intended, and hence the issue with this firmware as the Cable company IPTV stream box doesn't like it. Everything else though was fine with this setting enabled on this firmware.

I find this an interesting (point/observation) considering I doubt very many of us forum members truly are Wireless Network Engineers.
Perhaps it does happen on occasion... That an advanced feature isn't really doing anything (or what it's supposed too).
And although certain users enabled a feature with good intent, everything works for them as expected... UNTIL a more recent firmware upgrade fixes the feature.
Myself, I am NOT a network engineer... but I have a gut feeling...
-This may have happened to some extent with the Enable 160 MHz Channel bandwidth feature?
And perhaps... It's currently happening with WMM & WMM APSD (PowerSaving)?
But I'm just theorizing.

 

[skeal]

Myself, I am NOT a network engineer... but I have a gut feeling...
-This may have happened to some extent with the Enable 160 MHz Channel bandwidth feature?
And perhaps... It's currently happening with WMM & WMM APSD (PowerSaving)?

I agree, a default WIFI setup should be tried first to determine if an advanced setting causes this issue.

 

[Morris]

Thanks for your suggestion, I'll check out this setting on my S22Ultra (Android 13) - maybe it's a potential problem generator. But in my WiFi network iPhone 13 and S21Ultra (Android 13) work fine with the "random MAC" option turned on - no problems!

If you live in the US and live near an airport or anyplace where you see or hear aircraft you should not be using DFS channels.

 

[Keenan]

If you live in the US and live near an airport or anyplace where you see or hear aircraft you should not be using DFS channels.

Like near a hospital that has a helipad.

 

[Morris]

I find this an interesting (point/observation) considering I doubt very many of us forum members truly are Wireless Network Engineers.
Perhaps it does happen on occasion... That an advanced feature isn't really doing anything (or what it's supposed too).
And although certain users enabled a feature with good intent, everything works for them as expected... UNTIL a more recent firmware upgrade fixes the feature.
Myself, I am NOT a network engineer... but I have a gut feeling...
-This may have happened to some extent with the Enable 160 MHz Channel bandwidth feature?
And perhaps... It's currently happening with WMM & WMM APSD (PowerSaving)?
But I'm just theorizing.

I'm a retired network manager so I know a bit. I'm not running the beta yet I have the following firmware:
Router: RT-AX-86U firmware 386.7_2
Node: RT-AX-86U firmware 3.0.0.4.388_21709 (Native code)
Node: ZenWiFi XD6 firmware 3.0.0.4.388_21380 (Native code)

I use 80-Mhz wide channels due to airport proximity in the US.

My WMM settings:
Enable WMM - Enable
Enable WMM No-Ack - Disable
Enable WMM APSD - Enable

I believe the above is the default.

I disable Airtime Fairness, it can lead to strange issues of the type described. I'm also suspicious of your 160 wide channels.

I have 802.11ax/ac Beamforming enabled and Universal Beamforming disabled.

I have no reported drops and no slowdowns. My nodes have the newer code, so I think you and the others should be looking at settings. Something may have change between versions that's affecting your setup.

If you are near an airport or see or hear aircraft regularly you should disable DFS and then there will be no 160 wide or at least there should not be.

As a general rule for configuring, never change a default unless you have a good reason to do so and this means understanding what the setting dose and the implications of the change.

Good luck!

 

[BlackPerl]

Running RT-AX86S and 388.1_beta3
I have changed network monitoring (under administration -> system) to untick dns query and tick ping with 9.9.9.9
Also rebooted router.
Still getting a dns query from the router every minute to dns.msftncsi.com so the tick box is not working.
I think this was an error in the original ASUS code base which was corrected by Merlin in a previous release of the code.
Has this fix been missed from the latest Merlin code base merge ?

 

[ColinTaylor]

Still getting a dns query from the router every minute to dns.msftncsi.com so the tick box is not working.
I think this was an error in the original ASUS code base which was corrected by Merlin in a previous release of the code.
Has this fix been missed from the latest Merlin code base merge ?

This is not an error. It's intentional behaviour and not a bug in the beta code (see past explanations from RMerlin about this).

 

[anotherengineer]

The last-minute IPv6 firewall issue made it necessary, as otherwise I was ready to release 388.1 final this weekend. I needed to ensure it didn't cause any new issue, hence the extended beta cycle.

Have any clue when the AC models will have a possible F/W on the horizon?
Thanks

 

[Treadler]

Running RT-AX86S and 388.1_beta3
I have changed network monitoring (under administration -> system) to untick dns query and tick ping with 9.9.9.9
Also rebooted router.
Still getting a dns query from the router every minute to dns.msftncsi.com so the tick box is not working.
I think this was an error in the original ASUS code base which was corrected by Merlin in a previous release of the code.
Has this fix been missed from the latest Merlin code base merge ?

Try ticking both boxes, & in addition to your 9.9.9.9, use ‘dns.quad9.net’ as your dns query.
No more Microsoft then, (plenty of Quad9 though).

 

[RMerlin]

Have any clue when the AC models will have a possible F/W on the horizon?

After I'm done with 388.1, so no ETA. All I know for now is I won't be able to obtain updated 386 GPLs until late December or sometime in January, so the next 386 update will be fairly minor.

 

[small_law]

Like near a hospital that has a helipad.

Or, as I understand it, a local TV station with weather radar on the roof of its building, which is my issue.

Bottom line is mileage will vary. For one of my 5 GHz networks, I use channel 36 as my control channel and I have no issues channel bonding up to 160 MHz. With the other, if I set channel 100 as my control channel and enable 160 MHz, no dice. The router gives me only 80 MHz because I'm within range of something using the DFS channels needed for 160 MHz, likely that TV station's weather radar. The building is a block away from me.

That's actually the way it's supposed to work; if the router detects DFS channels in use around you, it won't let you use those channels. You can see it in your wireless logs ("channel cleared for radar").

If you have a Wifi 6E (6 GHz) router, device compatibility with lower channels can get weird. My understanding (and please correct me if I'm wrong) is that some devices either don't support or won't check for the lowest PSC's. My phone was having issues scanning for my 6E network when the control channel was set lower than 37.

 

[jeton7608]

From your suggestions (v. 388.1 Beta4):

1st step: I turned off the "random MAC", restart the AX86 system --> S22 Ultra connected for a while and then the connection to WiFi was broken. Connection slowdown Tx 68Mbps / Rx 6Mbps, no internet connection.

2nd step: I turned off power saving (WMM APST = Disable), restarted the AX86 --> S22 Ultra connected for a while and then the connection to WiFi was broken. Connection slowdown Tx 68Mbps / Rx 6Mbps, no internet connection.

And one more thing, before 388.1Beta4 I had firmware, stock 388.21709 - and the same problems connecting the S22 Ultra to WiFi.

Now I'm back to 386.5.2, no hard reset - S22 Ultra connects without problems at full speed, Tx/Rx = 2401.9Mbps (5GHz/160MHz). Fast connection and very stable!

In my case "S22 Ultra", connection problems started with firmware version 386.7--->388.1 Beta4.

I own an Asus GT-AX11000 and I was curious about this post and another one above and checked my S22 Ultra and it's true. The phone placed next to the router showed 2.4Gbps at connection and almost instantly changed to 1.6Gbps. And the router was 1 feet away. I tried this with 388.1 b3 and b4.

Once I reflashed 386.5 Merlin firmware version, it's stable at 2.3/2.4Gbps and 20 feet away it holds 1.4Gbps. I have installed the latest firmware in my S22 Ultra. I don't know what could have happened after 386.5 version.

 

[Damit1]

Tried the IPv6 new implement thing. I guess it is ISP bug but took me 30m-1h to obtain IPv6 after a while did not obtain at all.
Working essentially

 

[fallenoracle]

I reported this. Further troubleshooting revealed that this is not specific to the Merlin firmware, but an Asus implementation issue in general — the same occurs with the latest 386 Asus baseline and the recently released 388 Asus baseline for the GT-AXE16000. The issue is that the GT-AXE16000 does establish the appropriate VLANs (VLAN ID 501 for 2.4 GHz, VLAN ID 502 for 5 GHz, and, I assume, VLAN ID 503 for 6 GHz) on the AiMesh node(s). Using "brctl show" via ssh makes it completely clear (see screenshots). I have been attempting to address this via Asus tech support for about 3 weeks, but I have not had any success as of yet.

I found that disabling the original and creating a new guest network under the same name with the same settings seems to resolve this issue, at least for now. 388.1 beta4.

 

[capncybo]

I own an Asus GT-AX11000 and I was curious about this post and another one above and checked my S22 Ultra and it's true. The phone placed next to the router showed 2.4Gbps at connection and almost instantly changed to 1.6Gbps. And the router was 1 feet away. I tried this with 388.1 b3 and b4.

Once I reflashed 386.5 Merlin firmware version, it's stable at 2.3/2.4Gbps and 20 feet away it holds 1.4Gbps. I have installed the latest firmware in my S22 Ultra. I don't know what could have happened after 386.5 version.

While I do not own such a high-end device to test with I must state...
That is BLAZENLY-FAST & my guess is... to attain that sort of WiFi Speed you would require 160MHz.
@tetar & others (who were also using 160Mhz) have been expressing their displeasure with how the more recent Asus firmware seems to be handling the 160MHz DFS.
Their common view or statement is basically... "It worked better & was more stable before" (such as on 386.5).
So Here's the BIG Question.
Was the older Asus firmware implementation actually acting in violation of proper 160MHz DFS behavior?
Meaning... although some were experiencing excellent local speeds & throughput...
The router was being a BAD Neighbor & (perhaps) it's behavior was technically illegal from a regulated airwaves standpoint.

OR Perhaps... Every complaint regarding (BLAZENLY-FAST-160MHz devices) is legit & something really has gone a-miss with the newer firmware(s)...
But Alas, it's closed-source WiFi code & therefore completely out of RMERLIN's control.

However I really would like to see an official "ASUS" answer to my BIG Question above.
And hopefully someday we'll know.