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

[RMerlin]

Asuswrt-Merlin 3006.102.1 Beta is now available for the RT-BE96U and the GT-BE98_PRO. This is the first release based on the new 3006 code, and also the first release to include WIfi 7 devices.

Do not ask about support for other models. 3006.102.1 will only support these two models (plus the GT-BE98 by Gnuton), and we will re-evaluate things after that realease is finalized on any other potential device to support. These must be picked in collaboration with Asus as GPL code and device samples (in the case of new devices) are necessary for each individual model.

Changelog:

3006.102.1 (xx-xxx-2024)

  This is the initial release of Asuswrt-Merlin based on
  the 3006 codebase.  Only a few specific models are
  currently available, more will be added over time as
  Asus progressively migrates devices to the new codebase.

  3006 introduces a number of major features, these will not
  be listed - please review Asus' own documentation on the
  new features added in 3006 (AKA Asuswrt 5.0).  The two most
  notable ones are VLAN and Guest Network Pro (also called
  Self-Defined Networks, or SDN), both of which are supported
  in Asuswrt-Merlin.

  This initial 3006.102.xx release also includes a number of
  potentially breaking changes over 3004.  The most relevant
  ones will be listed below.

  Note that while Asus uses VPNFusion, Asuswrt-Merlin still
  uses VPNDirector.  The integration with Guest Network Pro
  had to be re-implemented to work with Asuswrt-Merlin,
  which required a few backend changes.

  Due to the VPN backend differences, it's strongly recommended
  to do a factory default reset after coming from the original
  Asus firmware if you used any VPN-related functionality.


  - NEW: Added support for GT-BE98_PRO.
  - NEW: Added support for RT-BE96U.
  - NOTE: Wifi 7 devices don't support NFS (issue with new
          toolchain), QoS classification page (issue with
          TrendMicro BWDPI) or Wifi Radar (not updated by
          Broadcom).
  - NEW: Added dnsmasq-INDEX.conf.add and stubby-INDEX.yml.add,
         which are appended to SDN config files (INDEX = SDN
         index number)
  - NEW: Added dnsmasq-sdn.postconf and stubby-sdn.postconf.
         They take two arguments:
           - path to the config file for that SDN's instance
           - the SDN index number (1 for the first SDN instance)

  - NEW: Rewrote VPN killswitch implementation.  The new method
         uses an always present routing rule to prohibit access to
         the main routing table, so it will be active even if the
         user manually stops a client.  Removing the prohibit rule
         requires disabling the killswitch on the webui.
         The rules are also created before WAN goes up, to reduce
         the risks of leaks between WAN going up and VPN connecting.
  - NEW: Added killswitch support for WireGuard clients.
  - UPDATED: Merged with GPL 3.0.0.6.102_34369.
  - UPDATED: Chart.js was upgraded from 2.x to 3.9, to share the
             same version used by Asus.  Any third party addon
             that used it will need to upgrade their charts to
             the new version.
  - UPDATED: wget to 1.24.5.
  - CHANGED: Switched to a different qrcode generation script, to
             share the same script used by Asus.
  - CHANGED: WireGuard and OpenVPN clients use different iproute2
             table IDs, to be in line with Asus's own table IDs.
             The names defined in rt_tables remain unchanged.
  - CHANGED: Implemented support for Wifi 7 and SDN on the
             Wireless Log page.
  - CHANGED: Implemented DNSDirector webui for SDN.
  - CHANGED: Removed stop/start and "Start with WAN" buttons from
             OpenVPN clients.  There is now just a single
             "Enable" option, which will immediately start the
             client when applying changes, and will also start it
             automatically when WAN comes up.  This is to reduce
             confusion, better integrate into SDN, and match how
             WireGuard clients already worked.
  - CHANGED: ipset is now compiled into the kernel rather than as
             modules (to match with Asus)
  - CHANGED: Removed led_disable nvram, we now share the same AllLED
             nvram as used by Asus for the LED button (and AiMesh sync)
  - FIXED: JS error on Wifi 6e/7 models when toggling DDNS.
  - REMOVED: Option dns_local_cache from Tools -> Tweak settings,
             to avoid issues with SDN that run their own
             dnsmasq instances.
  - REMOVED: Wifi Radar was removed (unsupported by Wifi 7 devices,
             and security issues cited by Asus in their own recent
             releases).

Things to test in particular:

• Guest Network Pro. Test with a VPN client, make sure traffic gets properly routed
• New killswitch implementation. Test various OpenVPN scenarios.
• Wireguard killswitch implementation. Test various scenarios.
• Test Wireless Log display with Guest Network Pro clients
• Test Wireless Log display with WIfi 7 clients (I only did limited testing by connecting another router as I don't have any Wifi 7 client)
• DNS Director tied to a Guest Network

For Addons developers:

• Chart.js was updated to 3.9. The 3004.388 branch will also be upgraded with 388.8, so get your addons updated if they use chart.js.
• The qrcode Javascript library was changed, as I switched to the same library Asus uses for Guet Network Pro. This change will only apply to 3006 firmwares.
• If your addon deals with VPN or routing, make sure they still work properly with the 3006 changes. iproute2 table IDs were changed for wgc and ovpn clients for instance (the ID changed, but the names remained the same)
• Each Guest Network can run its own dnsmasq instance. If your addon modified dnsmasq.conf, then you will need to adjust.
• Note that WIfi 7 routers are still based on kernel 4.19 (but a newer minor revision), the same Entware ARM 64-bit repo still works fine.
• ipset is now compiled built into the kernel rather than as a module, to match with Asus. If you use ipset, don't try to modprobe modules under 3006. I might apply that to 3004.388 as well, undecided yet.
• 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.

There may be other changes that affect script authors, as I don't know what internal structures or variables they may be interfacing with.

Please keep discussions on testing of these two devices. Off-topic posts will be ignored, moved or deleted, based on my mood at the time.

Downloads are here.
Changelog is here.

 

[RMerlin]

Known issues:

• Adaptive QoS is not working (Same issue upstream, I cannot do anything about it)
• No Changelog on the website (need to be implemented in the CMS cod CMS module updated with support for the new changelog)

 

[RMerlin]

Ramdom notes:

The new killswitch implementation will eventually be backported to 388 models (including for Wireguard, as the new implementation makes it possible now).

The 3006 code is currently stable enough (i.e. I don't foresee any major changes during the beta cycle) for script and addon developers to start updating their code to work with the new changes. One of the biggest changes is probably the chart.js migration. I also initially feared how much work would be required to port existing code as the Chart.js developer seems to put very limited efforts in retaining full backward compatibility between major versions, but it wasn't that bad in the end. I recommend looking at the changes made to the Tools_Sysinfo or the QoS_Stats pages as a reference as to what needs changed. These changes can easily be tested using a 3004 firmware as well, just load a new version of Chart.js on top of the old one.

I know that the Entware installer from amtm does work fine so far (so that means basic amtm functionality seems fine as well). LED control, VPN routing, Chart.js are probably the biggest areas that might require adjustments from script authors. Anything dealing with dnsmasq.conf as well, as you have to take into account Guest Networks now that can run their own instances of dnsmasq. Custom scripts were added for these, I am open to feedback if the implementation of these scripts are not currently flexible enough.

 

[GHammer]

I'm not using VPN so can't test any related items.
However, beta 1 over alpha 2 comes up and runs fine.
No issues with IPv4 and IPv6 port forwarding.

 

[GHammer]

I'm setting up an ASUS GT-BE98 Pro with the current beta of 3006.102.1 and have come to the part where I need to add to dnsmasq
On my old AX86U, dnsmasq.conf.add went into jffs/configs
Is this the same location on the new build and hardware?
Is it going to have the same format now that different SDNs and such are being addressed in dnsmasq?

Here's the content of my file:

strict-order
add-mac
add-subnet=32
local=/0.100.10.10.in-addr.arpa/

Thanks.

 

[RMerlin]

I'm not using VPN so can't test any related items.
However, beta 1 over alpha 2 comes up and runs fine.
No issues with IPv4 and IPv6 port forwarding.

Do you have Wifi 7 clients? Everything looking good on the Wireless Log page?

 

[RMerlin]

I'm setting up an ASUS GT-BE98 Pro with the current beta of 3006.102.1 and have come to the part where I need to add to dnsmasq
On my old AX86U, dnsmasq.conf.add went into jffs/configs
Is this the same location on the new build and hardware?
Is it going to have the same format now that different SDNs and such are being addressed in dnsmasq?

Here's the content of my file:

strict-order
add-mac
add-subnet=32
local=/0.100.10.10.in-addr.arpa/

Thanks.

Do you use any Guest Network? If no, then nothing has changed. However if you have a Guest Network, then it will run a second dnsmasq instance if that GN has its own subnet, and you will need to also have a dnsmasq-1.conf.add (assuming you have just one Guest Network) to implement the same thing to the Guest Network.

 

[betovanbuuren]

Dirty flashed over Alpha2 build. Testing guest network pro with 2 different clients one ovpn and another with wireguard, both pointing to Argentina Country, testing with services like disney + and star+ streaming apps, neither are showing local Argentina's catalog, is like I am still in my Country with no vpn client enabled. Strange thing is if I go to myiplocation pages in google i can see is pointing to Buenos Aires, however those apps wont recognize / honor my vpn location (not sure why).

The same happened in alpha builds.

Then if I go to my main wifi with normal vpn director, works correctly with no issues, seems isolated to guest network pro vpn network.

 

[RMerlin]

however those apps wont recognize / honor my vpn location (not sure why).

Make sure you set the OpenVPN routing to "VPN Director / Guest Network" on the client configuration, otherwise traffic won't be redirected through it.

Also, make sure IPv6 is not enabled on these clients, as that would totally bypass an IPv4 tunnel.

Unfortunately, redirecting IPv6 traffic is not really an option due to the volatile nature of IPv6 addresses.

If checking your location through a webpage works fine, then it's possible these clients are using a different method than your IP address to determine your region. They may be relying on DNS queries for example.

 

[betovanbuuren]

Make sure you set the OpenVPN routing to "VPN Director / Guest Network" on the client configuration, otherwise traffic won't be redirected through it.

Also, make sure IPv6 is not enabled on these clients, as that would totally bypass an IPv4 tunnel.

Unfortunately, redirecting IPv6 traffic is not really an option due to the volatile nature of IPv6 addresses.

If checking your location through a webpage works fine, then it's possible these clients are using a different method than your IP address to determine your region. They may be relying on DNS queries for example.

I've set an Argentina DNS for that guest network ovpn and seems to be working now.

The OpenVPN routing option was already to "VPN Director / Guest Network" on the client configuración.

Do you recommend to use openvpn instead of wireguard due with WG there is no routing option to configure?

 

[RMerlin]

I've set an Argentina DNS for that guest network ovpn and seems to be working now.

If that VPN client is using OpenVPN, you could also try setting the client DNS mode to "Enforced", which would redirect those client's DNS traffic through the DNS server provided by the VPN. If their provided server works properly with geolocation, that might be another option for you.

Do you recommend to use openvpn instead of wireguard due with WG there is no routing option to configure?

For routing purposes both should be fine, especially since you are binding it to a Guest Network. Wireguard might be slightly faster, but that traffic will bypass NAT acceleration so it might lead to higher general CPU usage (CPU usage from the VPN crypto + CPU usage from the packet forwarding). Go with whichever works best for you, this might also depend on the VPN server's performance.

 

[betovanbuuren]

If that VPN client is using OpenVPN, you could also try setting the client DNS mode to "Enforced", which would redirect those client's DNS traffic through the DNS server provided by the VPN. If their provided server works properly with geolocation, that might be another option for you.

Do you mean the option "Accept Dns Configuration"? In ovpn client?

There is no Enforced but strict and exclusive though

 

[RMerlin]

Do you mean the option "Accept Dns Configuration"? In ovpn client?

View attachment 59329

There is no Enforced but strict and exclusive though

Sorry, I meant Exclusive indeed.

 

[betovanbuuren]

Sorry, I meant Exclusive indeed.

If I select exclusive under access dns Configuration, do I need to configure those dns somewhere (dns director)? Or it does automatically via the .ovpn file directly already configured?

 

[Broken Hope]

I understand the reasons why but it’s a shame you’re not supporting the GT98 directly.

I’m sure Gnuton does a good job but based on 3004.388.7 it’s looking like their version releases substantially later then yours does

 

[RMerlin]

If I select exclusive under access dns Configuration, do I need to configure those dns somewhere (dns director)? Or it does automatically via the .ovpn file directly already configured?

It will use whatever DNS server is pushed to you by the VPN server.

 

[GHammer]

Do you have Wifi 7 clients? Everything looking good on the Wireless Log page?

I do. The wireless log looks good, but for the WiFi 7 client, only the MAC is shown, the device name is shown in Network Map, client list.

Not a huge deal to me, but nice if it were the device name as the 2.4 and 5 band clients.

 

[RMerlin]

I do. The wireless log looks good, but for the WiFi 7 client, only the MAC is shown, the device name is shown in Network Map, client list.

Is the device connected directly to one of the radios, or is it connected through a Guest Network or MLO?

The hostname is extracted from DHCP leases from dnsmasq, so it shouldn't matter if the client is Wifi 6 or 7.

Can you post a screenshot (with the MACs blurred if needed)?

 

[bal3wolf]

thank you @RMerlin for all your hard work, i use QOS on my router and the Traditional QoS still works the way it should with your firmware.

 

[GHammer]

Is the device connected directly to one of the radios, or is it connected through a Guest Network or MLO?

The hostname is extracted from DHCP leases from dnsmasq, so it shouldn't matter if the client is Wifi 6 or 7.

Can you post a screenshot (with the MACs blurred if needed)?

It is directly on the router and MLO has been disabled.