What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

[ 3006.102_4 alpha Build(s) ] available build(s)

If people want to help me test something that will save me time: can you guys please test if disabling, and re-enabling the LEDs on the Administration->System page works properly? I implemented a simpler way of handling LEDs in 3006, and so far it was only tested with Wifi 7 devices. I need to ensure that it works fine also on Wifi 6 models that got migrated to this new code.

That will save me from having to plug and test all 6 models myself (I only tested one so far).
Works fine on 86U Pro!
 
Upgraded my GT-AX6000 from Alpha 1 to Alpha 2.

Both this and the previous upgrade removed the executable permission for several scripts, which I could fix by a `chmod u+x` for those scripts.

All these scripts are links to files in the clone of a Git(Hub) repository on the JFFS partition.
 
If people want to help me test something that will save me time: can you guys please test if disabling, and re-enabling the LEDs on the Administration->System page works properly? I implemented a simpler way of handling LEDs in 3006, and so far it was only tested with Wifi 7 devices. I need to ensure that it works fine also on Wifi 6 models that got migrated to this new code.

That will save me from having to plug and test all 6 models myself (I only tested one so far).
LED on/off works fine on GT-AXE16000.

I noticed an interesting thing on the alpha2. My internet radio reports an error that it cannot get an IP from the DHCP server when connecting to WiFi. It has a fixed IP set for it in the router. The router log shows the device (without an IP), but it does not work. If I enter the data for the connection manually (enter the IP and the gateway address on the internet radio), it works fine. On the alpha1, the connection worked with DHCP as well.
 
Last edited:
Upgraded my GT-AX6000 from Alpha 1 to Alpha 2.

Both this and the previous upgrade removed the executable permission for several scripts, which I could fix by a `chmod u+x` for those scripts.

All these scripts are links to files in the clone of a Git(Hub) repository on the JFFS partition.
That sounds like the work of the asd daemon/demon.
 
If people want to help me test something that will save me time: can you guys please test if disabling, and re-enabling the LEDs on the Administration->System page works properly? I implemented a simpler way of handling LEDs in 3006, and so far it was only tested with Wifi 7 devices. I need to ensure that it works fine also on Wifi 6 models that got migrated to this new code.

That will save me from having to plug and test all 6 models myself (I only tested one so far).
LEDs turn on and off with your system setting on the AX86U Pro.
It also works both on your firmware and stock firmware by toggling LEDs on/off by going into the AI Mesh section (even when not using AI Mesh), then Management tab (on top right side). You then get an option for on/off LED toggle.
 

Attachments

  • Screenshot_20250319-211405.png
    Screenshot_20250319-211405.png
    317.6 KB · Views: 43
Hi, but the axe11000 dont have support?
 
Hi, but the axe11000 dont have support?
The four year old GT-AXE11000 model doesn't currently list any stock Asus 3006 firmware for it. So likely no it will not be supported by Asus-Merlin 3006 firmware.
 
LED control in Administration>System works on my GT-AX6000. With Alpha2 my wireless logs seem to be working so far as I can tell, and custom scripts all seem okay. One oddity: LAN> VLAN: Profile changes the subsection tab to "Switch Control" even though the page contents is for setting VLAN Profiles/IDs
 
If people want to help me test something that will save me time: can you guys please test if disabling, and re-enabling the LEDs on the Administration->System page works properly?

Worked in ZenWIFI Pro XT12 enabling and disabling.
 
The four year old GT-AXE11000 model doesn't currently list any stock Asus 3006 firmware for it. So likely no it will not be supported by Asus-Merlin 3006 firmware.
the date its the same of axe16000. So i dont understand why dont have the same supp. But its asus soo...
 
the date its the same of axe16000. So i dont understand why dont have the same supp. But its asus soo...
Hi, but the axe11000 dont have support?

I have this router as a test node, the thing that I think throws people off is it's an AXE model; though it's not a PRO model.
For example the GT-AX6000 is not 6GHz compatible, but it received 3006 firmware; same with many of the other "PRO" AX models.

And as @karateca mentions, it lines up date wise with other releases that received 3006.

I think the real issue right now for ASUS is the SoC that the GT-AXE11000 uses; which is the Broadcom BCM4908 and the Broadcom BCM43684 for WiFi.
You'll notice none of the supported 3006 models use that Broadcom SoC.

If they did release it for the GT-AXE11000, they would likely also release for the GT-AX11000 and RT-AX95U which also use that Broadcom SoC.
Not saying it's impossible, I still have hopes ASUS will turn around and add/announce support to more AX models down the line, but so far I'm not holding my breath. (i'd turn blue real quick.)
 
I have no idea if it's a bug, but you can no longer log in under "Parental Control - Adguard" when "Two-Factor Authentication" is activated in your Adguard account. You can only log in again after deactivating it.

What I also find very disappointing is that you cannot adjust the "Display of local device names" through that interface.
 
That sounds like the work of the asd daemon/demon.
Didn’t think of that, but you might be right!

Would that also be an explanation for a p10k.zsh script being deleted every now and then? (That happened with 3004 as well; the -x I have not experienced before)
 
GT-AXE11000 is BCM4908 and Linux kernel 4.1 (older Broadcom SDK).
GT-AXE16000 is BCM4912, Linux kernel 4.19, and newer Broadcom SDK.

Asus hasn't officially announced their plans for these older models, but my personal opinion is that chances of them moving to 3006 at this point are very slim. The cutoff isn't randomly based just on the age, it's also related to the software and hardware platform itself.

That does not mean the end of support for these models. 388 will still receive bugfixes, and possibly even a few enhancements, judging at how Asus did that in the past with the 382/384/386/388 series. Heck, devices that have been EOL for 10 months now are still getting occasional bugfixes.

Asus router owners have been spoiled IMHO by the fact that they often get brand new features to their existing devices. This is very uncommon in the market of these AIO home routers, where new features are generally only reserved for new models.

When you bought the router initially, it was for its existing feature set at the time. Any future feature addition should be taken as a bonus, not as granted.
 
If people want to help me test something that will save me time: can you guys please test if disabling, and re-enabling the LEDs on the Administration->System page works properly? I implemented a simpler way of handling LEDs in 3006, and so far it was only tested with Wifi 7 devices. I need to ensure that it works fine also on Wifi 6 models that got migrated to this new code.

That will save me from having to plug and test all 6 models myself (I only tested one so far).
Dirty upgrade from 388.8_4 to alpha 2, leds working properly on ax11000pro
 
If people want to help me test something that will save me time: can you guys please test if disabling, and re-enabling the LEDs on the Administration->System page works properly? I implemented a simpler way of handling LEDs in 3006, and so far it was only tested with Wifi 7 devices. I need to ensure that it works fine also on Wifi 6 models that got migrated to this new code.
Interesting – when I reported a problem a long time ago that the LED settings on my XT12 spoke (not on the master hub) were ignored on every reboot (they are always on afterward, even though they were configured to "off"), I was told that the LED control was a "closed" part of ASUS code and therefore couldn't be influenced.
If this has now changed, I'm glad, and I hope this problem can be solved.
I'll try to find some time for testing in the coming days.

P.S. If anyone else is already testing XT12 configurations (with hub/spoke setup) with this alpha version, please consider doing that as well.
 
Interesting – when I reported a problem a long time ago that the LED settings on my XT12 spoke (not on the master hub) were ignored on every reboot (they are always on afterward, even though they were configured to "off"), I was told that the LED control was a "closed" part of ASUS code and therefore couldn't be influenced.
Previously:
- Code turning LEDs off is Asus' closed source
- Code turning LEDs on was partly mine (per model) and partly Asus's closed source
- Code sharing the LED status between AiMesh nodes is closed source.


Now:
- Code turning LEDs off and on is Asus' closed source
- Code sharing the LED status between AiMesh nodes is still closed source.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top