[Dev] Asuswrt-Merlin 388.1 development

[BlackIce]

I got tired of waiting around for ASUS to implement Wireguard. I purchased a $80 GL.iNet Flint Router and have been using it in front of the ASUS router for some time now. The Flint router does the WIreguard and passes the LAN out to the WAN in of the ASUS the Flint router also does the routing for my VOIP (VOIP Adapter exempted form VPN). Was extremely easy to implement. (Yes I could have done it doing the Merlin addons route but wanted to try the GL.iNet router given the ever increasing prices of the ASUS routers. I've been very happy with the GL.iNet Flint router and have not had to touch the LAN configs on the Asus router (I just DISABLED OVPN). I've seen 300Mbps down on my Wireguard (Which is the top of what I can get via Starlink in the middle of the night). I'll continue to use this configuration and standby to see the how things go on the ASUS side of things.
Running OpenWrt 21.02-SNAPSHOT r16399+157-c67509efd7 on the Flint Router.
Edit: Forgot to mention that my VPN Provider is SURFSHARK. Which I understand currently only supports Wireguard on the router on DD-WRT and Open-WRT.

 

[SomeWhereOverTheRainBow]

The more I work with Wireguard, the more I dislike it.

- No way to get any actual debug logging unless running Kernel 5.6+ (or if there is, no documentation mentions it, they all talk only about kernel debugging with 5.6+) Makes debugging anything a big guessing task.
- No concept of a "client disconnecting" - once a peer (client) contacts another one (server), it will stay forever there, with no way of knowing that the "client" has disconnected - that's because to Wireguard, there are no client and servers connecting, just peers talking to one another

Wasted a few hours last night implementing and testing reporting connected "Clients", until discovering that it's useless because clients never truly go away. So that VPN Status code will have to be half scrapped.

And that's on top of the fact that it's incompatible with NAT hardware acceleration, that it uses a cypher that has no hardware acceleration, and that various VPN providers require a custom implementation and/or don't provide any downlodable config file to configure it manually. Asus had to implement dedicated support for NordVPN and HMA, which I will most likely not be offering in Asuswrt-Merlin since it's part closed-source, and part tied to VPNFusion, which I don't support.

Frankly, nothing but drawbacks from a router's point of view when compared to OpenVPN, or even IPSEC.

The only thing I personally have ever found advantageous about wireguard is the easy for do it yourself'ers to implement on a rpi or small home setup. In this regard, openvpn and wireguard are both pretty simple to setup. Wireguard may offer some advantage when it comes to speed on certain platforms. (obviously not our asus routers though).

Not on a router.


OpenVPN involves exporting a config file, and importing on a client - just as easy.


I don`t know what Yazfi does. I do have plans to investigate a potential way of allowing VPNDirector to also deal with interfaces rather than just IP addresses, if that's what you mean.

As far as I can tell, those who love wireguard have tried it on other setups and experienced its "potential". They say, "hey wouldn't this be cool on a router?" Well maybe it would be if the router technology was upgraded along side it, but asus isn't going to pay those big dollars and forsake broadcom contracts. Personally, I would have just stuck with the openvpn implementation at the router level.

This is not me bashing Wireguard. I am just on RMerlin side when I say, "it could have been done better, or not at all."

 

[SomeWhereOverTheRainBow]

I don`t know what Yazfi does. I do have plans to investigate a potential way of allowing VPNDirector to also deal with interfaces rather than just IP addresses, if that's what you mean.

A quick easy button that allows one to properly router guestnetworks or site-tunnel through vpn client would be awesome.

 

[RMerlin]

Running OpenWrt 21.02-SNAPSHOT r16399+157-c67509efd7 on the Flint Router.

Apparently that Qualcomm's FE acceleration works better with the Wireguard protocol. Maybe eventually Broadcom will decide it will be worth the effort of also ensuring better support for that protocol within their SDK stack, but we're not there at the moment.

 

[RMerlin]

A quick easy button that allows one to properly router guestnetworks or site-tunnel through vpn client would be awesome.

Guest Network (and even band-specific) might be doable, that's what I need to investigate once I'm done with the current task of integrating WG support. I'm about half done with the webui side of things now, I was able to implement a VPNStatus design that I'm more satisfied with, unlike the previous mess that filled two pages of server/client blocks.

Not final design yet (I need to experiment with a better layout idea I have, but I ran out of time for this today as I need to get back to daytime work stuff):

(and before someone mentions it - those tunnels are between two routers within my LAN. So no, I don't care about showing these keys on a public forums, those are internal test setups, not exposed to the Internet.)


I had the idea for GN support by looking through the VPN Fusion code last night as I was trying to find more info on their WG integration. VPNFusion seems to have (finalized or experimental) code to handle interface-specific routing.


After a week of progress, it seems that my TODO list keeps growing longer.

 

[SomeWhereOverTheRainBow]

Guest Network (and even band-specific) might be doable, that's what I need to investigate once I'm done with the current task of integrating WG support. I'm about half done with the webui side of things now, I was able to implement a VPNStatus design that I'm more satisfied with, unlike the previous mess that filled two pages of server/client blocks.

Not final design yet (I need to experiment with a better layout idea I have, but I ran out of time for this today as I need to get back to daytime work stuff):

View attachment 44506

(and before someone mentions it - those tunnels are between two routers within my LAN. So no, I don't care about showing these keys on a public forums, those are internal test setups, not exposed to the Internet.)


I had the idea for GN support by looking through the VPN Fusion code last night as I was trying to find more info on their WG integration. VPNFusion seems to have (finalized or experimental) code to handle interface-specific routing.


After a week of progress, it seems that my TODO list keeps growing longer.

I would rather you take your time and have something brilliant, than rush something for the sake of those who want to see the next version number. Keep up the hard work!

 

[Calkulin]

Hi everyone,

Just to give a little progress report on 388 development.

View attachment 44451

I would of thought the 388 SDK used newer drivers than what 386.5 had. Did this test build have the same driver rollback that 386.7_2 had?

 

[RMerlin]

would of thought the 388 SDK used newer drivers than what 386.5 had. Did this test build have the same driver rollback that 386.7_2 had?

For HND 5.02axhnd (RT-AX88U and GT-AX11000) I have only noticed minor SDK changes. No idea what changed within the binary wireless driver itself, I used whatever was present in the new GPL archive.

388 is Asus' base firmware code, it's not a Broadcom SDK. So far Asus has been applying SDK updates to both the 386 and 388 branches.

 

[JGrana]

Did read that correctly that Asus is now going with their own SDK (or forked BCM SDK) going forward? If so, quite admirable of Asus - and I would think a big advantage for Asus routers and us users.

 

[Damit1]

@RMerlin

Do you plan on getting new AX88U for the development?
I trully hope so, using WG on your WEBUI should be amazong

 

[Clark Griswald]

@RMerlin

Do you plan on getting new AX88U for the development?
I trully hope so, using WG on your WEBUI should be amazong

After reading this thread, I can't wait until the newest developments are finalized, and I can move from WireGuard (on Pi4) to OpenVPN on router. As stated in post #42 I used WG for the simple installation on the RPi, yet want to use OpenVPN on the router. With the OpenVPN (#26) and RMerlin 388-1 developments, I think it's time to leave WG and begin the OpenVPN/VPNDirector path on my router! Currently I'm too weak to fight the battle to have my Family change their devices.

EDIT: In response to RMerlin's question (post #52) my answer is Simplicity. I had The Wife and Kids "scan" the qr code on their (apple devices) and they were connected. The WG installation for RPi is so simple it puts Griswald Easy at a new level.

 

[RMerlin]

Do you plan on getting new AX88U for the development?

Yes, I already filed a demand for a replacement.

Did read that correctly that Asus is now going with their own SDK (or forked BCM SDK) going forward?

You can't fork an SDK for a hardware platform that is from a different manufacturer. An SDK is the software a hardware manufacturer provides to work with that hardware. So, only Broadcom can develop an SDK for a Broadcom chip.

After reading this thread, I can't wait until the newest developments are finalized, and I can move from WireGuard (on Pi4) to OpenVPN on router. As stated in post #42 I used WG for the simple installation on the RPi, yet want to use OpenVPN on the router. With the OpenVPN (#26) and RMerlin 388-1 developments, I think it's time to leave WG and begin the OpenVPN/VPNDirector path on my router! Currently

I don't understand why you are waiting for a 388.1 release for this, since there are currently zero changes planned for OpenVPN in that release.

 

[ZebMcKayhan]

Apparently that Qualcomm's FE acceleration works better with the Wireguard protocol. Maybe eventually Broadcom will decide it will be worth the effort of also ensuring better support for that protocol within their SDK stack, but we're not there at the moment.

As it turns out, not all Wireguard configurations requires NAT hw accelleration to be turned off. For example a site-2-site type of configuration does not suffer from this incompability, probably because no nat involved in lan-2-lan communication. Guess that would also include a server peer if only lan data is over Wireguard and no internet data.

Will you disable FlowCache no matter what? Or let it be a user choice?

 

[DJones]

As it turns out, not all Wireguard configurations requires NAT hw accelleration to be turned off. For example a site-2-site type of configuration does not suffer from this incompability, probably because no nat involved in lan-2-lan communication. Guess that would also include a server peer if only lan data is over Wireguard and no internet data.

Will you disable FlowCache no matter what? Or let it be a user choice?

Just to chime in on this a bit their are situations with asus routers where NAT hw acceleration would still have to be disabled for example if you run Quality of Service - Cake or using Bandwidth Limiter. As for the root of your question that’s something Rmerlin can answer.

 

[torstein]

I may have misunderstood, but is the OpenVPN kernel improvements to increase speeds already in place or is that a feature that is coming to asus-merlin at some point?

 

[DJones]

I may have misunderstood, but is the OpenVPN kernel improvements to increase speeds already in place or is that a feature that is coming to asus-merlin at some point?

Their is no speed improvements to openvpn the discussion started with how wireguard has some performance benefits in hardware that is not routers. Rmerlin was saying if OpenVPN was to get a performance benefit these are the things that would help increase performance. They (OpenVPN) haven’t implemented anything, neither has Asus. Have a quick reread of the discussions.

“OpenVPN's next real step forward is the current work to offload the data handling portion to the kernel, which would reduce context switches, and allow to better leverage hardware-acceleration beyond just CPU operands.”

“And once OpenVPN gets DCO finalized, it should in theory also allow OpenVPN to leverage a hardware SPU, which means both lower CPU usage and higher throughput. Or you can go for just higher throughput by leveraging multithreading instead of an SPU, but with a higher CPU usage.”

Sorry I’m kinda to blame I steered the discussion into this as fascinating as it is to hear it has nothing to do with this dev build.

 

[RMerlin]

Will you disable FlowCache no matter what? Or let it be a user choice?

If Asus' code does, then yes, it will be disabled.

 

[RMerlin]

I may have misunderstood, but is the OpenVPN kernel improvements to increase speeds already in place or is that a feature that is coming to asus-merlin at some point?

OpenVPN DCO is still under development from the OpenVPN developers, and won't be available until OpenVPN 2.6.0. And it's currently unknown what kernel version will be required to support this feature.

 

[DJones]

OpenVPN DCO is still under development from the OpenVPN developers, and won't be available until OpenVPN 2.6.0. And it's currently unknown what kernel version will be required to support this feature.

https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26

Schedule ¶​

Too early to say, but we hope to get this done quicker than 2.4 and 2.5 - so, tentatively (as of August 18 2022):

• all "must have" code in (except TLS handshake): Mid-October 2022
• RC candidates: November 2022
• 2.6.0 release: December 1st 2022

 

[torstein]

@DJones and @RMerlin Thanks for answering. I asked because I wasn't sure, since the article Rmerlin linked to wrote this:

• ovpn-dco-win is currently available as a tech preview and will officially be available as part of the 2.6 release in Q4 2021.

So I had to ask, since that tech-preview was almost a year ago, if it was finished now and implemented in one way or another. Thanks for clearing that up But,

@DJones wrote:
Their is no speed improvements to openvpn

Rmerlin wrote:
And once OpenVPN gets DCO finalized, it should in theory also allow OpenVPN to leverage a hardware SPU, which means both lower CPU usage and higher throughput. Or you can go for just higher throughput by leveraging multithreading instead of an SPU, but with a higher CPU usage.

Doesn't "higher throughput" mean faster speeds, DJones? The graphs in the article over at openvpn also shows graphs with higher speeds. So whenever OpenVPN 2.6.0 is released, and Rmerlin adds it in his firmware, and the kernel in ie my router AX86U supports it, shoudn't that increase speeds? Again, I'm just a layman with an interest in computers and networking, so I'm just asking to learn.