Announcement: 3006 progress report - it's a go

[TurnstileBlues]

This looks incredible

 

[robinjoo1]

wooow
what a good news hope my GT-AX11000 PRO will get it

 

[HeadBanger]

The 3006 firmware’s main draw seems to be the VLAN capability. Bar ring-fencing multiple LANs from others where additional security is needed, does this bring other benefits to home users who are currently happily running one LAN? Are there any performance gains to be had for example?

Thanks!

HB

 

[RMerlin]

The 3006 firmware’s main draw seems to be the VLAN capability. Bar ring-fencing multiple LANs from others where additional security is needed, does this bring other benefits to home users who are currently happily running one LAN? Are there any performance gains to be had for example?

VLANs are just one component of SDN (Self-Defined Network), also referred to as MultiLAN. You can, for example, create a new Guest Network, have it completely isolated from the rest of your network (it will even run its own DHCP server), and have it tied to a VPN client so that any client you connect to that Guest Network will automatically be routed through that VPN. Makes it easy if you want to toggle VPN tunnelling for a wireless client - just connect to a different SSID. Got a work laptop that needs VPN access to the office? Setup the VPN on a guest network, and connect the work laptop to that network.

MultiLAN alone is a very major change in 3006 as it integrates into multiple areas of the firmware.. Getting that integrated into Asuswrt-Merlin took me a whole week of intensive development (that was separate from the time needed to merge the 3006 code itself). Fortunately I had a fair amount of free time during that week, and I'm finally starting to see my ToDo list shrinking down.

There are also a few other features that are only available to business models, such as MultiWAN support (which is a more advanced version of the current Dual WAN).

 

[Gary_Dexter]

VLANs are just one component of SDN (Self-Defined Network), also referred to as MultiLAN. You can, for example, create a new Guest Network, have it completely isolated from the rest of your network (it will even run its own DHCP server), and have it tied to a VPN client so that any client you connect to that Guest Network will automatically be routed through that VPN. Makes it easy if you want to toggle VPN tunnelling for a wireless client - just connect to a different SSID. Got a work laptop that needs VPN access to the office? Setup the VPN on a guest network, and connect the work laptop to that network.

MultiLAN alone is a very major change in 3006 as it integrates into multiple areas of the firmware.. Getting that integrated into Asuswrt-Merlin took me a whole week of intensive development (that was separate from the time needed to merge the 3006 code itself). Fortunately I had a fair amount of free time during that week, and I'm finally starting to see my ToDo list shrinking down.

There are also a few other features that are only available to business models, such as MultiWAN support (which is a more advanced version of the current Dual WAN).

Will 3006 Merlin allow for configuring one-way and two-way etc. communications between VLAN’s?

For example I would want devices on the “normal” LAN to communicate with the IoT network, but not allow the IoT network to talk back to the “normal” LAN.

This is one of the things stopping me purchasing as new router that supports 3006 (yes, I know I can run YazFi).

 

[RMerlin]

Will 3006 Merlin allow for configuring one-way and two-way etc. communications between VLAN’s?

A VLAN is meant for isolation. Either they are isolated, or they aren't...

What you seek is something better handled by a firewall.

 

[Gary_Dexter]

A VLAN is meant for isolation. Either they are isolated, or they aren't...

What you seek is something better handled by a firewall.

Indeed. And like with Synology and Ubiquiti you can create firewall or traffic rules to allow certain communications.

I guess this won’t be a part of Merlin’s release?

 

[JoGi]

that's the best news
ALWAYS used Asus Merlin firmware but unfortunately had to go back (downgrade) to stock firmware because I could configure the VLANS more easily. (wired and wireless)

I can't wait for the merlin 3006 version to be released !

 

[RMerlin]

Indeed. And like with Synology and Ubiquiti you can create firewall or traffic rules to allow certain communications.

I guess this won’t be a part of Merlin’s release?

If it's not part of Asus' code, then it won't be part of Asuswrt-Merlin either. Everything related to VLAN will be entirely Asus' code.

 

[qq3748]

If it's not part of Asus' code, then it won't be part of Asuswrt-Merlin either. Everything related to VLAN will be entirely Asus' code.

Hi, can you disclose some more about the process of the latest 3006 firmware, and roughly how long it will take, I've got used to using the Merlin firmware, but at the moment I've got a really lot of devices now that have had to be upgraded to the newer ones with multiple ports, and would like to know roughly how long it will take to get it supported, and maybe perhaps maybe my model isn't supported, but I can re-purchase a multiport router that supports your latest firmware!

 

[RMerlin]

Hi, can you disclose some more about the process of the latest 3006 firmware, and roughly how long it will take, I've got used to using the Merlin firmware, but at the moment I've got a really lot of devices now that have had to be upgraded to the newer ones with multiple ports, and would like to know roughly how long it will take to get it supported, and maybe perhaps maybe my model isn't supported, but I can re-purchase a multiport router that supports your latest firmware!

At this time I don't have anything new to announce, sorry. How long it will take depends as much on how many obstacles I must work around, how long it will take me to implement/fix what needs to be, and how long it will take for Asus to provide GPL code for the models that I plan to support. So it's impossible to give any type of ETA.

 

[Dedel66]

I think everyone should now have a little more patience for what is coming.

 

[RMerlin]

Some development updates.

The SDN integration is almost done now (maybe 90% done), another large piece was done this weekend with integrating SDN guest networks into the Wireless Log page, including displaying VLANs used by a guest network. I still need to look at the VPN server side of SDN (something Asus themselves don't seem to have finalized yet either, as so far only WireGuard VPN server support seems to be enabled).

I'm taking the opportunity of this 3004 -> 3006 jump to make some lower level changes that might not be 100% backward compatible. I expect quite a few addons will be broken by it (like those that tie into guest networks or VPN), their developers will need to adjust once 3006 enters public testing. Best to break them all at the same time (as 3006 itself will break a few things), so they will only need fixing once.

Some of the things I still need to have a look at:

- Impact of SDN on DNSDirector. I believe Asus did most of the necessary work to integrate the two, but I still need to review those changes and adjust them if necessary
- Impact of SDN on VPNDirector. At first glance, SDN rules will have priority over VPNDirector rules. I still need to review and test the full interaction between the two however.
- Migrating Chart.js from 2.x to 3.x (sadly, Chart.js breaks all backward compatibility iin these major upgrades). That will require adjusting the generation code for all the charts shown by Classification, TrafficMonitoring and Sysinfo, something I had been postponing for quite some time due to the amount of work involved. It will be necessary if we ever need to support
Asus's dashboard since it uses Chart.js 3.9, and therefore would break any existing charts.
- Reviewing how the killswitch interfaces within the new SDN environment. I've already done some routing table changes to better match with upstream, I need to see how killswitch is affected by these changes.

Number of git commits since work began on the 3006 branch:

$ git log --oneline master..3006 | wc -l
67

As I mentionned earlier, I still cannot provide any ETA for public availability, as I'm still waiting on receiving a few requested model GPLs before I can get things public. Development-wise, most of the hardest work is done by now, and I have to say that initially I wasn't even sure if it would be doable, or how I could do it. This is why I waited until I was sure (i.e. that I had a somewhat working "proof of concept") just to announce that I would be going ahead with the 3006 merge. I had multiple scenarios on how I could possibly deal with SDN's integration.

The reason why I won't announce model support until things are 100% certain for all planned models is because I don't want to announce that, for example, I am supporting the RT-AA101, and have everyone rushing out to buy it. And a week later to announce "Oh, I am also going to support the RT-BIG9000", and now people who just bought the RT-AA101 complain that they would have preferred to have gone with that second model had they known it would be supported. Both Gnuton and I have currently a list of planned devices to support with 3006.102.1, the plan is to announce these models only after GPLs have arrived for them (or if some have to be left aside for now, we will know by then.)

 

[Viktor Jaep]

I'm taking the opportunity of this 3004 -> 3006 jump to make some lower level changes that might not be 100% backward compatible. I expect quite a few addons will be broken by it (like those that tie into guest networks or VPN), their developers will need to adjust once 3006 enters public testing. Best to break them all at the same time (as 3006 itself will break a few things), so they will only need fixing once.

Thanks for the heads-up on this, @RMerlin... could you please elaborate what kind of functionality would be broken for scripts that tie into VPN? Are you foreseeing changes to the way the VPN slots are setup, or how OpenVPN is being utilized? Thanks in advance... I'll definitely be running the alpha/beta for this big leap.

 

[Nagy Imre]

Thank you for your work.

I'm excited for GT-AXE16000 support. Plus vote for it.

 

[cc666]

Merlin,

How close is the code you are currently working with to the FW_GT_AXE16000_90061024856 Beta firmware released for the GT-AXE 16000?

CC

 

[Dedel66]

I think everyone should now have a little more patience for what is coming.

I don't like to quote myself, but...

 

[RMerlin]

could you please elaborate what kind of functionality would be broken for scripts that tie into VPN?

Hard to say as I have never looked at how any of these scripts worked. Some of the changes specific to OpenVPN cliients:

- The iproute2 table numbers were changed. Anything that relied on the names written in /etc/iproute2/rt_tables would be fine, however anything that used direct number will break. The number and also the order have changed - that was necessary to align with the SDN integration (so we shared the same table numbers, and the order matches how units are stored internally in SDN definitions). These numbers may also be different depending on whether a device has SDN support or not. Relying on rt_tables would be the safest way to handle it at this time.

- The presence of SDN rules through iproute2 (which all have higher priorities) may conflict if any script used an arbitrary prio value, and these values might possibly be used by SDN now. A VPN client may also be bound to a Guest Network instance, which means it will have higher priority rules in place affecting routing for that VPN client.

- Another change: OpenVPN clients no longer have separate "Start with WAN" and "Enable ON/OFF" toggles. There is just one single "Enable Client" now which reuses the same variable storage as Start with WAN, except that it will also be used when someone wants to stop/start a client. This makes thiings in line with how things were implemented with WG clients, it will also be less confusing (we occasionally get posts here from people confused about the On/OFf toggle switch not surviving a reboot). It should also make things cleared regarding the killswitch as people were also confused by the fact that only clients set to Start with WAN would be affected. Now, any client that runs would be affected, since a client HAS to be enabled for it to be running.

OpenVPN clients routing tables no longer contain a copy of the main table. I can't remember why I did it that way initially, but seeing that Asus themselves don't copy it, and the WG client never had any problem with their own tables also not having a copy of it, I decided to make things uniform there for OpenVPN clients.


For anything that deals with Guest Networks:

- Devices with SDN support may have up to 16 guest networks (unsure if all of them may be Wifi, at first glance it seems to be the case). Anything hardcoded for only 4 GN max will break. These can also have VLANs defined, so any script that played with VLANs may conflict with it


More general SDN-related things:

- SDN networks can have their own DHCP server. That means multiple instances of dnsmasq may be running, and they may have their own seprate lease list. Anything that deals with dnsmasq's configuration will have to be aware of that.


People who have addons that provide their own web UI will be affected by the Chart.js upgrade (if it does happen for 102.1). Charts created for 2.x will need to be adjusted to work with 3.x.


Those are the bigest ones I can think off right now by referring to my notes (I try to keep track of things that will need to be documented in the 102.1 changelog). Things are also still subject to change throughout development.

 

[RMerlin]

How close is the code you are currently working with to the FW_GT_AXE16000_90061024856 Beta firmware released for the GT-AXE 16000?

I'm working with 102_34369, which is much newer.

 

[RMerlin]

Another change I forgot because I only finalized it last night: QRCodes are now generated with a different library. Asus added a library which they use for QRCodes on the Guest Network page, so I reused that library for the QRCodes that I generate on the Wireless status page, including a nicer looking icon reused from the SDN UI. So any script that used the previous qrcode.min.js will have to switch to the new one. It's even simpler to use, however it's based on jquery.

$('#qr'+unit).qrcode({width: 160,height: 160,text: qrstring});

attaches a qrcode image to the <div> with id qr0, qr1, etc...


Some of these changes I might backport to 388 for consistency... Or I might keep only in 102, so third party devs could easily determine what is available just by looking at the major version number (388 would be old qrcode and old OpenVPN behaviour, 102 would be the new one). I haven't decided yet. That is something I will probably discuss with the community once things get into public testing.

The new router.asp page with its new QRcode icon that can be clicked on: