What's new

Asuswrt Merlin 3006.102.3 Alpha2 for GT-BE98 Pro, RT-BE86U, RT-BE88U, and RT-BE96U

  • 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!

visortgw

Very Senior Member
@RMerlin has posted firrmware 3006.102.3_alpha2-g9540bd8f43 for the GT-BE98 Pro, RT-BE86U, RT-BE88U, and RT-BE96U. Changelog shows:

Code:
3006.102.3 (xx-xxx-xxxx)
  - NOTE: If flashing on top of Asus stock firmware 3006.102_37000
          or greater, then you first need to enable downgrade
          capabilities before flashing Asuswrt-Merlin on top
          of it.  Over SSH, run the following command:

             nvram set DOWNGRADE_CHECK_PASS=1

          After that, you can upload Asuswrt-Merlin through
          the webui like any regular firmware upgrade.

          This is only required when flashing Asuswrt-Merlin
          for the first time.

  - NOTE: The new GPL codebase changed the way wireless networks
          are configured.  If you ever revert to an older
          firmware, you MUST do a factory default reset following
          the firmware downgrade, on both the router and any
          existing AiMesh nodes.

  - UPDATED: Merged with GPL 3006.102_37346 (with the wifi firmware
             from 37038 for the RT-BE96U and GT-BE98_PRO - was missing
             from GPL)
  - UPDATED: dropbear to 2024.86.
  - CHANGED: VPN public IP retrieval now uses HTTP instead of STUN,
             which should be more reliable through a VPN tunnel.
  - CHANGED: Refresh link not working on OpenVPN/Wireguard client pages.
             Also enhanced behaviour on the VPNStatus page.
  - CHANGED: Model name will be inserted in the filename of JFFS backups.
  - FIXED: webui always redirecting to router hostname for RT-BE86U.
  - FIXED: DLNA device icon missing for GT-BE98_PRO
  - FIXED: Site Survey page not loading properly
  - FIXED: Wireless Log would sometimes display the wrong hostnames
NOTE: Install at your own risk. Alpha builds are unsupported.


Download from the standard Pre-beta test builds on OneDrive.
 
Last edited:
@RMerlin: Based upon the change log comments, I cannot determine if the WiFi firmware for the GT-BE98 Pro has changed between alpha1 and alpha2:

Code:
- UPDATED: Merged with GPL 3006.102_37346 (with the wifi firmware
           from 37038 for the RT-BE96U and GT-BE98_PRO - was missing
           from GPL)

For whatever reason, I am seeing much better WiFi stability among router, AiMesh nodes, and devices in alpha2 over alpha1 (in the limited time that it has been installed).

Thanks again for everything that you continue to do for the Asuswrt-Merlin community.
 
How much time does it take until an alpha firmware goes over to beta? 1-2 months?
Want to wait until the beta version, before upgrading my router.
 
How much time does it take until an alpha firmware goes over to beta? 1-2 months?
Want to wait until the beta version, before upgrading my router.
Could be a few days, could be a few weeks. There's no set time, it moves to beta once I feel I am done with whatever I wanted to work on for this particular release.
 
After a flogging by the family today on many social websites they use, streaming services, outdoor cameras, Control 4, Roost, EV chargers, Purple Air, Emporia energy monitors, Solar inverters, my work stuff, all 100% (WiFi setup is Smart Connect). Roost monitors very picky, they happy with this 2.4GHz WiFi & connection. Thanks once again @RMerlin for the dedication & quality of Asuswrt-Merlin product.
 
Pleased to read that the latest fw is being received well, as usual.
But @nzwayne uploading an alpha fw, albeit RMerlin's, on a holiday?
My friend you have some serious thrill issues, and I'm glad you survived!
 
"The new GPL codebase changed the way wireless networks are configured"
I dirty flashed my BE88U... And before I realized where WPA settings and such went... 😉 A "Oh, shirt... wipe time" wasn't far away :)
 
Seem to have got the first problem. MLO Fronthaul. Does seem that some devices gets locked out and refuse to connect. And without it, they only use 2.4 GHz. Digging around a bit.

Update: Somehow I got up and running. Perhaps I waited too little time.
It's still an interesting chain of events.

At first WPA3 fell back to WPA2/3 mode on main. Others remained the same.
All devices were stuck on 2.4 (apparently all the time).
With MLO Fronthaul on, some devices did a "whatever, lets use 2.4 GHz" (Mac and iPad) while others refused to connect completely (2x OnePlus that supports WiFi-7, and a Pixel 7A)

Lets dig around some more :)

Some new rows in the log. (adding the more I discover to avoid multiple posts)

Dec 27 19:41:41 RT-BE88U-F1B8 kernel: blog_get_dstentry_by_id:dstid[692] match fails entry.dstid[820]
Time related right?
 
Last edited:
Seem to have got the first problem. MLO Fronthaul. Does seem that some devices gets locked out and refuse to connect. And without it, they only use 2.4 GHz. Digging around a bit.

Update: Somehow I got up and running. Perhaps I waited too little time.
It's still an interesting chain of events.

At first WPA3 fell back to WPA2/3 mode on main. Others remained the same.
All devices were stuck on 2.4 (apparently all the time).
With MLO Fronthaul on, some devices did a "whatever, lets use 2.4 GHz" (Mac and iPad) while others refused to connect completely (2x OnePlus that supports WiFi-7, and a Pixel 7A)

Lets dig around some more :)

Some new rows in the log. (adding the more I discover to avoid multiple posts)

Dec 27 19:41:41 RT-BE88U-F1B8 kernel: blog_get_dstentry_by_id:dstid[692] match fails entry.dstid[820]
Time related right?
 
Eric, Question for you, when using stock firmware, DHCP lease page show ip address assignment for all devices, regardless of which subnet or pool used, however, firmware published by you I am only able to see for my main LAN, not any other subnet, given it's already shown in stock variant, is it possible to see ip address for all the subnet, not just main subnet.
 
Eric, Question for you, when using stock firmware, DHCP lease page show ip address assignment for all devices, regardless of which subnet or pool used, however, firmware published by you I am only able to see for my main LAN, not any other subnet, given it's already shown in stock variant, is it possible to see ip address for all the subnet, not just main subnet.
The DHCP page is virtually identical to stock firmware, the only change I made was to ensure that it didn't restart the entire network whenever you made changes to it. And to "fake" lack of Fusion support so it wouldn't try to process the non-existing list of Fusion entries.

Code:
merlin@ubuntu-dev:~$ colordiff dev/amng/release/src/router/www/Advanced_DHCP_Content.asp gpl/asuswrt.102-37346-be96/release/src/router/www/Advanced_DHCP_Content.asp
119,124d118
< var lan_domain_ori = '<% nvram_get("lan_domain"); %>';
< var dhcp_gateway_ori = '<% nvram_get("dhcp_gateway_x"); %>';
< var dhcp_dns1_ori = '<% nvram_get("dhcp_dns1_x"); %>';
< var dhcp_dns2_ori = '<% nvram_get("dhcp_dns2_x"); %>';
< var dhcp_wins_ori = '<% nvram_get("dhcp_wins_x"); %>';
<
139,140d132
< vpn_fusion_support = false;
<
401,413d392
<
<         // Only restart the whole network if needed
<         if ((document.form.dhcp_wins_x.value != dhcp_wins_ori) ||
<             (document.form.dhcp_dns1_x.value != dhcp_dns1_ori) ||
<             (document.form.dhcp_dns2_x.value != dhcp_dns2_ori) ||
<             (document.form.dhcp_gateway_x.value != dhcp_gateway_ori) ||
<             (document.form.lan_domain.value != lan_domain_ori)) {
<
<             document.form.action_script.value = "restart_net_and_phy";
<         } else {
<             document.form.action_script.value = "restart_dnsmasq";
<             document.form.action_wait.value = 5;
<         }

EDIT: unless you meant the System Log page that shows existing leases, in which case I haven't looked yet at how it interacts with guest networks.

EDIT2: which is now done with this commit.
 
Last edited:
I think I found a bug.
On the RT-BE86U, in the client list, Windows clients are just shown with the naming "MSFT 5 0". Not with the correct client name.
I'm running NextDNS CLI on the router. There I see in the NextDNS logs, that the client names of the windows devices is shown correctly. But the client list in the Network Map windows, is showing it with "MSFT 5 0".
 

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!
Top