Beta Asuswrt-Merlin 3006.102.1 Beta is now available for WIfi 7 devices

[jsbeddow]

View attachment 59795

above is from GT-AX6000 no issues, also zero issues with AXE16000

Wait, what? As far as I can tell, there are no Merlin releases of the 3006.102.1 series for the GT-AX6000, only the RT-BE96U and the GT-BE98_PRO.

 

[visortgw]

Wait, what? As far as I can tell, there are no Merlin releases of the 3006.102.1 series for the GT-AX6000, only the RT-BE96U and the GT-BE98_PRO.

You are correct. I'm referring to GT-BE98 Pro with 3006.102.1 Beta 1 as in my signature.

 

[RMerlin]

Is hardware acceleration intentionally disabled?

No, unless you enable an incompatible feature such as Traditional QoS.

 

[jsbeddow]

You are correct. I'm referring to GT-BE98 Pro with 3006.102.1 Beta 1 as in my signature.

Yes, but my comment was directed to @Clark Griswald , who referenced the hardware acceleration features being turned on on a GT-AX6000, but that model doesn't have a build (yet) under the Merlin 3006 branch (although I suppose he could be referring to the status while running the latest stock AsusWRT builds).

 

[visortgw]

No, unless you enable an incompatible feature such as Traditional QoS.

Traditonal QoS was never enabled. I don't recall making any change(s) that should have affected this, but I now manually enabled both runner and flow cache.

As always, thanks again for all of your efforts!

 

[Clark Griswald]

@jsbeddow @visortgw
I removed my post, due to posting in wrong area
visortgw
My Goodness, You have quite the plethora of higher end routers in your signature. I bow in respect my friend!

 

[thelonelycoder]

LED enable/disable was changed. Instead of our own led_disable nvram, we now reuse the AllLED nvram that Asus uses for the LED button. This will allow to sync it with AiMesh nodes. Anything that can manipulate LEDs will need to adjust. This will eventually be ported to 3004.388 as well.

NVRAM AllLED is present in at least 3004.388.7, how could I determine in future releases that this should be used instead of led_disable?
With the *BE9x routers it's simple (buildno=102.1) but what about future updates to 388x branch? Will they have an incremental greater buildno than 388.7 or will it be 390 or something?

 

[RMerlin]

NVRAM AllLED is present in at least 3004.388.7, how could I determine in future releases that this should be used instead of led_disable?

AllLED is the variable that Asus has been using for years now, tied to either the physical button or to the mobile app.

I will probably eventually apply the same change to 388, but I won't have time to do it for 388.8 since that requires me to test every individual model to determine if Asus's proprietary code is fully working or not.

If you want to play it safe, I would say change both variables (AllLED and led_disable). setup_leds() was already setting the AllLED variable in addition to the Asuswrt-Merlin led_disable variable, the only two changes will be:

- setup_leds() will directly call Asus' closed source functions instead of me having to manually track down every required register changes when enabling LEDs back whenever I add a new model
- The leds_disable nvram will no longer have any effect. The webui toggle will directly control AllLED.

With the *BE9x routers it's simple (buildno=102.1) but what about future updates to 388x branch? Will they have an incremental greater buildno than 388.7 or will it be 390 or something?

Only Asus knows if they intend to eventually have a 3.0.0.4.390_xxxxx firmware series or not.

 

[thelonelycoder]

AllLED is the variable that Asus has been using for years now, tied to either the physical button or to the mobile app.

I will probably eventually apply the same change to 388, but I won't have time to do it for 388.8 since that requires me to test every individual model to determine if Asus's proprietary code is fully working or not.

If you want to play it safe, I would say change both variables (AllLED and led_disable). setup_leds() was already setting the AllLED variable in addition to the Asuswrt-Merlin led_disable variable, the only two changes will be:

- setup_leds() will directly call Asus' closed source functions instead of me having to manually track down every required register changes when enabling LEDs back whenever I add a new model
- The leds_disable nvram will no longer have any effect. The webui toggle will directly control AllLED.


Only Asus knows if they intend to eventually have a 3.0.0.4.390_xxxxx firmware series or not.

Thanks, that helps a lot.

 

[visortgw]

No, unless you enable an incompatible feature such as Traditional QoS.

@RMerlin: I discovered that hardware acceleration was disabled again this morning. Traditional QoS has never been enabled. I'm puzzled as to what is causing the change.

 

[dave14305]

@RMerlin: I discovered that hardware acceleration was disabled again this morning. Traditional QoS has never been enabled. I'm puzzled as to what is causing the change.

See what’s in nvram:

nvram show 2>/dev/null | grep -E "^(fc|runner)_disable"

 

[visortgw]

See what’s in nvram:

nvram show 2>/dev/null | grep -E "^(fc|runner)_disable"

After re-enabling via "runner enable; fc enable", the web GUI confirms it is enabled:

but nvram shows this:

# nvram show 2>/dev/null | grep -E "^(fc|runner)_disable"
fc_disable=1
runner_disable=1

Do I need to change nvram variables as well?

 

[dave14305]

After re-enabling via "runner enable; fc enable", the web GUI confirms it is enabled:

View attachment 59823​

but nvram shows this:

# nvram show 2>/dev/null | grep -E "^(fc|runner)_disable"
fc_disable=1
runner_disable=1

Do I need to change nvram variables as well?

Check:

nvram get qos_enable
nvram get qos_type
nvram get rb_enable

 

[visortgw]

Check:

nvram get qos_enable
nvram get qos_type
nvram get rb_enable

# nvram get qos_enable
1
# nvram get qos_type
2
# nvram get rb_enable

 

[DJones]

After re-enabling via "runner enable; fc enable", the web GUI confirms it is enabled:

View attachment 59823​

but nvram shows this:

# nvram show 2>/dev/null | grep -E "^(fc|runner)_disable"
fc_disable=1
runner_disable=1

Do I need to change nvram variables as well?

I assume you rebooted after nvram commit?

 

[dave14305]

# nvram get qos_enable
1
# nvram get qos_type
2
# nvram get rb_enable

So it thinks Bandwidth Limiter is active.

 

[visortgw]

# nvram get qos_enable
1
# nvram get qos_type
2
# nvram get rb_enable

THANKS! You steered me in the right direction. Apparently, bandwidth limiter for one of my guest networks was enabled. I now turned it off.

 

[RMerlin]

3006.102.1 final has now been released. Thanks everyone who participed into this beta cycle.