[Dev] Asuswrt-Merlin 388.1 development

[SomeWhereOverTheRainBow]

as @SomeWhereOverTheRainBow just reminded us: "... with these routers you are lucky to push 350 mbps off of a 1gbps line speed without hardware acceleration."
So...
Why do some people still insist on talking-up wireguard?
Unless the Asus router CPU is replaced with something superior... The Wireguard Tunnel's network speed will never keep up with the current (almost-common) 1G ISP Connection.

One of the exceptions being a pure fiber connection, but i am not even sure if that would make a difference. Also, show of hands, how many of us can say our area provides us with a "pure" fiber connections?

 

[sfx2000]

Now regarding the cipher. ChaCha20 is immensely faster than AES256 due to having an impressively simpler implementation and *does not* need hardware acceleration. Running on software it is still *faster* than hardware accelerated AES256 90% of the time, making it ideal for general purpose and/or older CPUs and it also benefits extremely from SIMD extensions that are available almost everywhere (granted though that the authentication primitive utilized, Poly1305, is more complex in SIMD implementation than GCM). Is also a *far* more secure cipher, not prone to error (bad implementation) issues that AES often suffers from and also safe from related-key attacks.

ChaCha20-Poly1305 isn't "faster" than AES-128-gcm - it is however, more efficient on CPU's that do not have HW acceleration...

Recall that WG is in kernel space, so we don't have that trip from kernel to userland (aka OpenVPN) and the OpenSSL overhead.

The upside to WG is that it is relatively easy to configure for client/server (actually peer-peer), and it works nicely with the rest of the networking stack - unless of course, someone is out of kernel with NAT flow acceleration.

The downside, at present, is that WG is locked into chacha20-poly1305, and if there is ever a compromise there, folks are in for a bit of trouble to remediate.

The other challenge, and this is being worked on, is enterprise-level classes of service, and things like SSO, which, these things are important for IT decision makers.

I'm a big fan-boi of WG, it's easy to configure, relatively performant (similar to L2TP-IPSec), and it's in the kernel for Linux - other platforms, ports are happening, so it's all good.

 

[iceorbital]

dirty upgrade on gt-axe11000, no obvious problems surfaced so far.

 

[skeal]

One of the exceptions being a pure fiber connection, but i am not even sure if that would make a difference. Also, show of hands, how many of us can say our area provides us with a "pure" fiber connections?

Mine does, it's called fiber to the premise here. It is a complete fiber connection. SaskTel infiNet.

 

[jsbeddow]

Same here: FTTH, fiber to the home. Although technically there is still an ONT at the service entrance(garage) to convert to Ethernet cable through the inside of the house .

 

[Deleted member 22229]

Also, show of hands, how many of us can say our area provides us with a "pure" fiber connections?

Many. Here in Michigan AT&T is expanding fiber to the home all over the place and it's awesome. Unfortunately i had to move for a better job during covid and stuck back on Comcrap but it works. Nothing like FTTH.

 

[skeal]

Same here: FTTH, fiber to the home. Although technically there is still an ONT at the service entrance(garage) to convert to Ethernet cable through the inside of the house .

Yes, however fiber to the devices on your network is likely a ways-out from 2022. This also is not considered when talking about a "Pure" fiber connection. Fiber to the home, or premise what ever the name, just know that we are talking about a connection with a termination point inside the house, not on a pole.

 

[DJones]

Yes, however fiber to the devices on your network is likely a ways-out from 2022. This also is not considered when talking about a "Pure" fiber connection. Fiber to the home, or premise what ever the name, just know that we are talking about a connection with a termination point inside the house, not on a pole.

My isp recently installed FTTH it’s nice a symmetric connection. Their connections stay symmetric up to 150mbps down 150mbps up then for faster plans up to 1gbps down 150mbps up.

BACKBONE->ISP-OLT->Feeder fibre cables->Optical distribution point->FTTH(distribution fibre cables)->OutdoorFAT->Drop optical cables->VOIP/ONT->ROUTER

 

[pirx73]

Not DSLAM, ISP termination point for ONT is called OLT

 

[DJones]

Not DSLAM, ISP termination point for ONT is called OLT

Thanks was on DSL for a long time which was a DSLAM. Wasn’t sure of the term for it on fibre.

 

[sfx2000]

Not DSLAM, ISP termination point for ONT is called OLT

No...

 

[vdemarco]

I just installed this, on my Ax88U so far its working well.
It did crash once, but has been good since. (I think it kernel panic'ed but its all good now) i say it kernel paniced cuz the webpage went offline then a few seconds latter the wifi dropped.

All good now.

 

[Damit1]

4 days now running, no issues observed.
The flood of Kernel log issues from last FW is officially gone since that patch arrived!

Cheers!

 

[elorimer]

Recall that WG is in kernel space,

But only since kernel 5.6, i.e., none of these routers? I'm very confused on this point, to be honest.

 

[Nodens]

As for your comment about not needing hardware acceleration, that may be true for equipment with better processors, but with these routers you are lucky to push 350 mbps off of a 1gbps line speed without hardware acceleration. That is due entirely to the limitations of the cpu. It is not like we are attempting it in x86_64 platforms where the difference would be less significant.

The original point was that this is simply not true and I explained why.

Mean while none of this is to talk bad about wireguard, I use it on three of my home builds. I just mean to say it is more a testament on the poor choice of equipment it is being deployed. They can't even get the kernels up to date.

No worries, we're just having a technical discussion. No one is badmouthing anything

“HND 5.04 uses kernel 4.19.183 ~ Rmerlin”

What this means is getting Linux kernel 5.6 entirely depends on Broadcom/ASUS using it for its embedded devices ie routers. Unless wireguard fundamentally becomes a key need to ASUS it’s unlikely to be supported any time soon. Routers are not like Linux pc’s with the ability to swap kernels if you tried you’d break a lot of stuff. Anyways a common mistake even I’ve made.

No one said anything about swapping kernels or whatever. At some point devices will move to newer kernels though as they always have done so over the years. And there will be a time when 5.6 is actually very old. For the time being wireguard-linux-compat module can be built for older kernels just fine and I assume this is what Asus is doing.

My point was that Wireguard gives no user feedback if it fails to connect for one reason or another. It leaves the end user having to figure out on his own why the tunnel won't go up. Is it a misconfigured AllowedIP? The remote peer not being reachable? A mismatched private/public key? You are left guessing, while with another traditionnal VPN solution, you can have a quick glance at a log, which will tell you what is failing.

Right. You can enable verbose debug output though if you build it with "CONFIG_WIREGUARD_DEBUG" set. Am I right in assuming Asus is using wireguard-linux-compat module?

It might be superior if the goal is to have a permanent tunnel between two sites. But if you have an on-demand tunnel (like a VPN connection with a VPN provider which you might want to start/stop on demand), it becomes unintuitive.

I disagree. It might be a good design for some type of uses, but for other uses it's no replacement to an existing technology like IPSEC or OpenVPN. For the goal of having an on-demand tunnel with a VPN provider, it's a clunky solution.

If that is your requirement you can always bring the interface down. Nothing stops you from doing that. The default operation is roaming though. You can keep your laptop or mobile device switching networks on the go and still have a transparent connection to your VPN without any leaking.

No, the fact that it was merged in is proof that it has enough uses to be worth merging into mainline kernel. That does not mean it's a panacea to replace every existing VPN technologies. The fact that reiserfs was merged into the kernel never meant it was the future of filesystems, for example. And for a home router, with the hardware involved and the typical use case involved, wireguard is not the best option for end users to use.

Kinda a bad comparison since a lot of filesystems are merged into the kernel and it is imperative for data access to do so. How many VPN technologies have been merged into the kernel though? I respectfully disagree. I still have not met a single use case where I would switch back to OpenVPN. IPSEC is another story though, I'll concur on that.

I am pretty certain that wireguard is much faster than OpenVPN when running on these routers too (for the reasons I stated). I wanted to test myself as I want to move wireguard from the linux server to my RT-AX88U on my homelab setup. I'm willing to test and do some benchmarks (1Gpbs fiber). Is the alpha stable enough? I work remotely often and having tunnel to my homelab at all times is imperative, so if things have no chance to crash and burn I'll take the plunge, heh.

As a sidenote, thanks for all the work you're putting into the firmware. (Btw this is Nodens, the developer behind Asus ROG Realbench)

ChaCha20-Poly1305 isn't "faster" than AES-128-gcm - it is however, more efficient on CPU's that do not have HW acceleration...

Recall that WG is in kernel space, so we don't have that trip from kernel to userland (aka OpenVPN) and the OpenSSL overhead.

Notice I never said it's faster than hardware accelerated AES-128-GCM. I said faster than hardware accelerated AES-256-GCM. Big difference (40-20% difference in performance between the two, depending on many factors) BUT I'm willing to bet that in this ecosystem of CPUs it's actually faster than AES-128-GCM as well, mainly due to the reason you stated (overhead).

The downside, at present, is that WG is locked into chacha20-poly1305, and if there is ever a compromise there, folks are in for a bit of trouble to remediate.

Pretty sure a switch to Xchacha20-poly1305 is in order but I do not expect support for AES at all. There's no point to it from a technical viewpoint. In fact, I would not be surprised to see (X)chacha20-poly1305 acceleration extensions in ARM soon.
As a sidenote there's a lot of extensive research being done on optimizing poly1305 (although irrelevant for these CPUs since it's mostly on the AVX front).

The other challenge, and this is being worked on, is enterprise-level classes of service, and things like SSO, which, these things are important for IT decision makers.

Agreed. There is work being done on that front with external projects.

 

[sfx2000]

Pretty sure a switch to Xchacha20-poly1305 is in order but I do not expect support for AES at all. There's no point to it from a technical viewpoint. In fact, I would not be surprised to see (X)chacha20-poly1305 acceleration extensions in ARM soon.
As a sidenote there's a lot of extensive research being done on optimizing poly1305 (although irrelevant for these CPUs since it's mostly on the AVX front).

This is an answer-nonanswer - on wg - the algo's are hardcoded, so client/servers will all need updates if there is a compromise...

As I mentioned, there is no cpu "accerleration" on chacha20-poly1305 - they are compute hard - so it's all on the ALU's there. That being said, ARM/MIPS/x86 - most of that is sorted...

I work on MIPS24kc - and wg works well enough...

Intel/AMD might do a bit of SSE/AVX optimization... but it won't be AES specific like it was... similar to ARM with SIMD enhancements there.

 

[skeal]

No...

View attachment 44943

There are similarities in the structure used by my ISP.

 

[Nodens]

This is an answer-nonanswer - on wg - the algo's are hardcoded, so client/servers will all need updates if there is a compromise...

I know its hardcoded. The difference between Xchacha20 and chacha20 is that the first uses a 192bit nonce vs a 64bit nonce on the later (with the obvious benefits). It is pretty trivial to implement support for it and fallback if it's not supported on the endpoint. This is why I said that I expect this to be implemented and if I recall right it was discussed in the mailing list at some point.

As I mentioned, there is no cpu "accerleration" on chacha20-poly1305 - they are compute hard - so it's all on the ALU's there. That being said, ARM/MIPS/x86 - most of that is sorted...

You *don't* need any acceleration on chacha20. The implementation is impressively simple and light. But poly1305 can be optimized with better parallelization and it's there that we could see a specialized extension.

Intel/AMD might do a bit of SSE/AVX optimization... but it won't be AES specific like it was... similar to ARM with SIMD enhancements there.

The work being done that I mentioned is on current crypto libs with existing parallelization extensions.

I do feel we're derailing the thread though since it's about the alpha and not analysis on crypto primitives heh.

 

[SomeWhereOverTheRainBow]

I am pretty certain that wireguard is much faster than OpenVPN when running on these routers too (for the reasons I stated). I wanted to test myself as I want to move wireguard from the linux server to my RT-AX88U on my homelab setup. I'm willing to test and do some benchmarks (1Gpbs fiber). Is the alpha stable enough? I work remotely often and having tunnel to my homelab at all times is imperative, so if things have no chance to crash and burn I'll take the plunge, heh.

I appreciate your technical points; however, for a test of your recommendation to have true weight , we would have to have a non-fiber comparison of equal asuswrt equipment. Not every connection is going to be as impervious as fiber. A similar asymmetric cable connection would easily buckle to the bottleneck produced by the routers insufficient arm processors having to respond without the aid of hardware acceleration.

 

[RMerlin]

Am I right in assuming Asus is using wireguard-linux-compat module?

Might be, I don't know for sure. All I know is if it's a kernel module, and not a userland implementation.

I am pretty certain that wireguard is much faster than OpenVPN when running on these routers too (for the reasons I stated). I wanted to test myself as I want to move wireguard from the linux server to my RT-AX88U on my homelab setup. I'm willing to test and do some benchmarks (1Gpbs fiber).

The problem is the Wireguard protocol is not compatible with Broadcom Flow Cache (part of their NAT acceleration). That requires you to disable NAT acceleration to be able to use Wireguard, which will cap NAT throughput at around 300-350 Mbps max on an RT-AX88U (and that's without any VPN overhead). Whatever speed gain Wireguard might get, you end up being capped at around 300 Mbps, which isn't much faster than OpenVPN which can reach 220-250 Mbps on the same router. OpenVPN can run with Flow Cache still enabled, so that means anyone with an Internet connection faster than 300 Mbps cannot use Wireguard without seriously capping their whole Internet connection speed.

So in your case, you'd have to chose between 220 Mbps OpenVPN and 1 Gbps non-VPN throughput, or 300 Mbps Wireguard and 350 Mbps non-VPN throughput.