[Dev] Asuswrt-Merlin 388.1 development

[elorimer]

with nearly all 2.4 clients not connecting

I have a mesh node on 7_2 and my main ax88 on alpha2. It is a little difficult to tell, because the network map is a little ambiguous, and the AIMesh page jumps around. But I have two 2.4 clients unambiguously and stably connected on the ax88. While different router, different driver, this may be a stock issue.

 

[Damit1]

All is good here

 

[jerry6]

Most of it is around VPN, due to Asus rewriting the VPN UI, but also their integration of VPN Fusion on all models, which I don't use. The rest of the code was surprisingly easier to merge than 384 or 386 were at the time.

Thank you for the update and all the work you put in to bring us this great FW . wISH THERE WERE AWAY i COLD DONATE A FEW $$ but I don't have and will never use Pay pal . Feel like I'mcheating you having used your FW for the last 10 or 12 years

 

[skeal]

So I've been using OVPN for a long time now. Must be 5 years or more at the least. I knew nothing about Wireguard before this development. I loaded this latest alpha onto my AX88U and then went to Torguard for my configuration file. I just want to say how well the design of this feature in Asuswrt-merlin firmware is. The process was so easy. I had it working in under 3 minutes, it helps to follow the development though for sure. Kudos to @RMerlin for a very easy to use setup, and implementation. You are and will always be my network manager...lol.

As stated above in @jerry6 post I don't use PayPal anymore either. Can I send an e-transfer (I'm Canadian) to you? What email address do you prefer?
Steve

UPDATE: Just got my USA dedicated IP from Torguard, Netflix works awesome in 4k, using Wireguard. Even on more than one device. Cheers big ears!!

 

[skeal]

[Humor] On further investigation the @RMerlin donation thread is not of Eric's doing, it was setup by someone else that has Erics PayPal Link information to post. Eric gets the money not to worry here. I won't criticize PayPal here either, I just don't use it, the only thing I ever used PayPal for was to give donations to Eric. There has to be a better way though. It may be obvious why he hasn't setup his own thread and email and or cell number to send Canadian e-transfers to. His arrangement with Asus may not allow this. If this is the case someone would have to collect the money and pass it to Eric on the down low...LOL . This would be a stupid idea of epic proportions at best, and a deal breaker for Asus and all of us at worst. So I guess PayPal support for Eric is all there is. Unless @RMerlin sets up a better solution himself, it won't happen.

The wild thinking of a man after a few happy hour cocktails...Woo-Hoo! Cheers all!

Back to the topic at hand.

 

[SomeWhereOverTheRainBow]

On further investigation the @RMerlin donation thread is not of Eric's doing, it was setup by someone else that has Erics PayPal Link information to post. Eric gets the money not to worry here. I won't critisize PayPal here, I just don't use it, the only thing I ever used PayPal for was to give donations to Eric. There has to be a better way. It may be obvious why he hasn't setup his own thread and email and or cell number to send Canadian e-transfers to. His arrangement with Asus may not allow that. If this is the case someone would have to collect the money and pass it to Eric on the down low...LOL. This would be a stupid idea of epic proportions at best, and a deal breaker for Asus and all of us at worst. So I guess PayPal support for Eric is all there is. Unless @RMerlin sets up a better solution himself, it won't happen.

The wild thinking of a man after a few happy hour cocktails...Woo-Hoo! Cheers all!

Back to the topic at hand.

I think the biggest issue here is users think they are paying @RMerlin for a service. That is not the case, he has been doing his work for free and will continue to do such as he sees fit and is able. The donation link is merely there for those who wish to show that type of appreciation. People show appreciation in there own way. Some people get offended if they cannot show it in their own way. I myself have donated to several developers on here. Obviously I have not made it known before because it truely was my way of saying thank you. I do not want them to feel any obligations towards it what so ever. It was meant as a token of gratitude and respect. Who cares who posted the link. It is posted for those who wish to show that gratitude, not to be the object of everyone's objections. If there was a problem with the way it was posted, it would have already been dealt with. If there is a problem with the link "now" it is because someone is trying to make a problem out of it.

 

[shabbs]

FWIW, the donation link is also on his official site... https://www.asuswrt-merlin.net/contact

 

[SomeWhereOverTheRainBow]

FWIW, the donation link is also on his official site... https://www.asuswrt-merlin.net/contact

And you bring the voice of reason! So obviously the user who posted the link was merely re-posting the link @RMerlin himself uses on his own website. There is such a thing as being to skeptical. I think this is one of those instances.

 

[SomeWhereOverTheRainBow]

To reiterate to the skeptics, the link is merely there for those who wish to show gratitude. (For those who wish to donate, it isn't required to boast throughout the thread "Hey, Merlin- I hope you got what I sent." because that is not what donating is about.) It is merely a way to say thank you if that is your way of showing it.

 

[skeal]

I was having fun, but seriously there should be more options than PayPal to offer Eric a cash support contribution. IMHO. I've contributed this way in the past but won't be able to continue in the future. Something easier to do than having to setup a payment client is my point. I am eternally grateful for the development he does and his expertise in network and computer management. I meant no trouble. Cheers!
Steve

 

[SomeWhereOverTheRainBow]

I was having fun, but seriously there should be more options than PayPal to offer Eric a cash support contribution. IMHO. I've contributed this way in the past but won't be able to continue in the future. Something easier to do than having to setup a payment client is my point. I am eternally grateful for the development he does and his expertise in network and computer management. I meant no trouble. Cheers!
Steve

If you message him personally he may give you a location you can send a gift card or check to, if donating to him a different way really means that much to ya. IMO, if receiving money was a necessity to keep developing Asuswrt-Merlin, then I am sure he would have more than one payment option. By him having only paypal, shows me he is not interested in recieving a fortitude of funds from everybody for maintaining and developing his firmware. To me, it speaks more to @RMerlin character.

HERE HERE!

 

[SomeWhereOverTheRainBow]

Now this thread needs to go back on to Discussion TOPIC ^^^^[Dev] Asuswrt-Merlin 388.1 development^^^^ and not that we are tipsy and feel like talking about @RMerlin Donation methods.

 

[DJones]

Well I’ve been running 388.1_alpha1-g8ea471fa9e non rog UI, since Sunday on my ROG GT-AX11000 and as far as I’m concerned it’s been very stable I did a dirty install and have had no noticeable issues with connectivity, stability, or with my entware since the awk issue was fixed upstream. Feels like a release candidate to me at minimum with my device, other devices may experience different issues.

Likely will stay alpha until he gets the GPL builds for the rest of the routers, and can test them all.

So far I’m very happy with it. No drops to the discovery of my nodes with priority wifi AImesh with failover Ethernet as secondary; earlier versions were much more fickle and I’d have to setup the node again if I rebooted too many times testing or making changes.

 

[Nodens]

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

The reasons you dislike it though are actually features. Perhaps you're too accustomed to the openvpn flow of things.

- 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.

This is not entirely correct. I assume you got this info trying to google for details. 5.6 is when the linux kernel merged wireguard in (2019), so from 5.6 and afterwards, it's native to the kernel and obviously if you want to debug the kernel you need to do kernel debugging.
Prior to 5.6 you need to build the wg module and load it yourself or use the userspace implementation written in go. So getting debug output depends on how you build the module and what you use. I assume Asus is providing binary blobs and pretty sure they would be built as release.

The thing is though that you don't actually *need* to debug the kernel module, unless you're actually doing development on it. It will print out errors in syslog and wireguard-tools have output that can be handled (wg-quick etc etc).
But if you need to do that during your development you can clone the old repo and build wg with debugging information. Here's the repo: https://git.zx2c4.com/wireguard-linux-compat/about/
Also here's the wireguard-go repo in case Asus is not using the kernel module: https://git.zx2c4.com/wireguard-go/about/
And here is the newer rust implementation in case it uses that: https://git.zx2c4.com/wireguard-rs/about/

Wireguard merged in the linux kernel is a feature. It has a performance benefit and streamlines things. It is actually the future. I've been a very early adopter of the alpha builds, using it on my production servers for years now and as an engineer I have been following its development closely on the wg mailing list. The initial draft that got into the kernel is not the original design (the one the compat repo uses). Changes were requested by the kernel maintainers and it's a WIP with a roadmap of eventually achieving the original implementation.

- 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

This is also a feature. Wireguard has built in roaming support. There is no concept of disconnecting. As long as there's internet connectivity between the 2 ends, packets will flow. As long as you've bound an application to an interface or ip, or as long as you're routing there via other means (eg namespaces) there's no chance of a leak. The interface will not go down, and once your internet connectivity to the other end is restored, packets will begin to flow as normal. This is superior design. BUT if you need to check if there's anything wrong, for some reason, you can always just ping the other end. Still if your configuration is right and you have a working tunnel, traffic will only not flow if the other end is shutdown or unreachable via the internet.

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.

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.

Now what a lot of VPN providers do, is not wireguard's fault but all the big ones that offer wg, so far, have caved in and offer a way to get manual configs even if it's a bit convoluted (eg PIA).


Seriously though, wireguard is the future, it's not a hype. The fact that it has been merged natively into the linux kernel is proof of that (if not its technological and performance superiority). This is why everyone is jumping on this bandwagon, including big companies. Once kernel 5.6 is utilized, all you need for implementation is the wireguard-tools package and some kind of GUI for the tools to benefit UX.

 

[DJones]

The reasons you dislike it though are actually features. Perhaps you're too accustomed to the openvpn flow of things.


This is not entirely correct. I assume you got this info trying to google for details. 5.6 is when the linux kernel merged wireguard in (2019), so from 5.6 and afterwards, it's native to the kernel and obviously if you want to debug the kernel you need to do kernel debugging.
Prior to 5.6 you need to build the wg module and load it yourself or use the userspace implementation written in go. So getting debug output depends on how you build the module and what you use. I assume Asus is providing binary blobs and pretty sure they would be built as release.

The thing is though that you don't actually *need* to debug the kernel module, unless you're actually doing development on it. It will print out errors in syslog and wireguard-tools have output that can be handled (wg-quick etc etc).
But if you need to do that during your development you can clone the old repo and build wg with debugging information. Here's the repo: https://git.zx2c4.com/wireguard-linux-compat/about/
Also here's the wireguard-go repo in case Asus is not using the kernel module: https://git.zx2c4.com/wireguard-go/about/
And here is the newer rust implementation in case it uses that: https://git.zx2c4.com/wireguard-rs/about/

Wireguard merged in the linux kernel is a feature. It has a performance benefit and streamlines things. It is actually the future. I've been a very early adopter of the alpha builds, using it on my production servers for years now and as an engineer I have been following its development closely on the wg mailing list. The initial draft that got into the kernel is not the original design (the one the compat repo uses). Changes were requested by the kernel maintainers and it's a WIP with a roadmap of eventually achieving the original implementation.


This is also a feature. Wireguard has built in roaming support. There is no concept of disconnecting. As long as there's internet connectivity between the 2 ends, packets will flow. As long as you've bound an application to an interface or ip, or as long as you're routing there via other means (eg namespaces) there's no chance of a leak. The interface will not go down, and once your internet connectivity to the other end is restored, packets will begin to flow as normal. This is superior design. BUT if you need to check if there's anything wrong, for some reason, you can always just ping the other end. Still if your configuration is right and you have a working tunnel, traffic will only not flow if the other end is shutdown or unreachable via the internet.


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.

Now what a lot of VPN providers do, is not wireguard's fault but all the big ones that offer wg, so far, have caved in and offer a way to get manual configs even if it's a bit convoluted (eg PIA).


Seriously though, wireguard is the future, it's not a hype. The fact that it has been merged natively into the linux kernel is proof of that (if not its technological and performance superiority). This is why everyone is jumping on this bandwagon, including big companies. Once kernel 5.6 is utilized, all you need for implementation is the wireguard-tools package and some kind of GUI for the tools to benefit UX.

“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.

As for any development regarding the struggles of wireguard will let rmerlin discuss this if he chooses.

 

[SomeWhereOverTheRainBow]

]

“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.

As for any development regarding the struggles of wireguard will let rmerlin discuss this if he chooses.

Alot of @kernol swapping indeed.....

 

[S.claus]

After a while, my Traffic Analyzer tab just loads endlessly. It stops the entire UI from loading eventually
Still have internet access on devices just can't access the UI

Edit: UI becomes accessible after a while again but Traffic Analyzer is still unresponsive and breaks the UI again after opening the tab.

 

[SomeWhereOverTheRainBow]

The reasons you dislike it though are actually features. Perhaps you're too accustomed to the openvpn flow of things.


This is not entirely correct. I assume you got this info trying to google for details. 5.6 is when the linux kernel merged wireguard in (2019), so from 5.6 and afterwards, it's native to the kernel and obviously if you want to debug the kernel you need to do kernel debugging.
Prior to 5.6 you need to build the wg module and load it yourself or use the userspace implementation written in go. So getting debug output depends on how you build the module and what you use. I assume Asus is providing binary blobs and pretty sure they would be built as release.

The thing is though that you don't actually *need* to debug the kernel module, unless you're actually doing development on it. It will print out errors in syslog and wireguard-tools have output that can be handled (wg-quick etc etc).
But if you need to do that during your development you can clone the old repo and build wg with debugging information. Here's the repo: https://git.zx2c4.com/wireguard-linux-compat/about/
Also here's the wireguard-go repo in case Asus is not using the kernel module: https://git.zx2c4.com/wireguard-go/about/
And here is the newer rust implementation in case it uses that: https://git.zx2c4.com/wireguard-rs/about/

Wireguard merged in the linux kernel is a feature. It has a performance benefit and streamlines things. It is actually the future. I've been a very early adopter of the alpha builds, using it on my production servers for years now and as an engineer I have been following its development closely on the wg mailing list. The initial draft that got into the kernel is not the original design (the one the compat repo uses). Changes were requested by the kernel maintainers and it's a WIP with a roadmap of eventually achieving the original implementation.


This is also a feature. Wireguard has built in roaming support. There is no concept of disconnecting. As long as there's internet connectivity between the 2 ends, packets will flow. As long as you've bound an application to an interface or ip, or as long as you're routing there via other means (eg namespaces) there's no chance of a leak. The interface will not go down, and once your internet connectivity to the other end is restored, packets will begin to flow as normal. This is superior design. BUT if you need to check if there's anything wrong, for some reason, you can always just ping the other end. Still if your configuration is right and you have a working tunnel, traffic will only not flow if the other end is shutdown or unreachable via the internet.


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.

Now what a lot of VPN providers do, is not wireguard's fault but all the big ones that offer wg, so far, have caved in and offer a way to get manual configs even if it's a bit convoluted (eg PIA).


Seriously though, wireguard is the future, it's not a hype. The fact that it has been merged natively into the linux kernel is proof of that (if not its technological and performance superiority). This is why everyone is jumping on this bandwagon, including big companies. Once kernel 5.6 is utilized, all you need for implementation is the wireguard-tools package and some kind of GUI for the tools to benefit UX.

Hey I understand wireguard being in top teir equipment, and even equipment we have the chance to build at home ourselves. The biggest problem here seems to be watching asus struggle on trying to stream line it to customers. 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. 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.

 

[skeal]

Now this thread needs to go back on to Discussion TOPIC ^^^^[Dev] Asuswrt-Merlin 388.1 development^^^^ and not that we are tipsy and feel like talking about @RMerlin Donation methods.

Now this thread needs to go back on to Discussion TOPIC ^^^^[Dev] Asuswrt-Merlin 388.1 development^^^^ and not that we are tipsy and feel like talking about @RMerlin Donation methods.

No need to get personal bud, I was having a little fun here as so many others have. No complaints from me about staying on topic, it seems hard to do these days in these threads. I'm sure though Eric doesn't require you to answer such tom foolery for him. IMO. End of discussion. Cheers!
Steve

 

[egc]

WireGuard also runs very good on older kernels with Wireguard Compat, it is the reason I switched one of my routers to DDWRT which already has Wireguard natively implemented from the beginning which tripled my speed compared to OpenVPN.
So it will be a big plus (and long overdue) if Asus and Asus-WRT-Merlin will finally get it