This...This is a Test Firmware Build, expect bugs.
Just curious if OpenVPN 2.6.0. could be implemented by RMerlin in the next alpha/beta? Interesting due to data channel offloading and increased speed in this release. And if/when eventually this release will be implemented in non-AX models. Is a newer kernel relevant for non-ax models?
DCO support is not possible, it requires kernel 5.3 or newer.Interesting due to data channel offloading
Yes thats is where i was afraid of. Im not into the kernels, but a quick search on the internet is the release of the 5.3.18 kernel was in 2019. Is there any asus router who will support the new kernel?DCO support is not possible, it requires kernel 5.3 or newer.
Kernel version is determined by the SoC manufacturer (Broadcom in this case). They don`t upgrade kernels, once a platform is launched, it stays on that kernel.Yes thats is where i was afraid of. Im not into the kernels, but a quick search on the internet is the release of the 5.3.18 kernel was in 2019. Is there any asus router who will support the new kernel?
Do you think it will work on the current kernels of asus routers?DCO support is not possible, it requires kernel 5.3 or newer.
** Kernel compatibility **
ovpn-dco is developed against the latest David Miller's net-next tree.
However, a compat layer is provided to allow people to compile ovpn-dco
against older kernel versions.
No. As I said, the newest routers use 4.19, and the DCO module requires 5.3.Do you think it will work on the current kernels of asus routers?
Ok, I just thought their README was implying that it could be backported to older kernels.No. As I said, the newest routers use 4.19, and the DCO module requires 5.3.
We had performance issues with OpenVPN some years back due to context-switching of the TUN/TAP devices having a syscall for every packet read op. An optimized userspace clone of OpenVPN was therefore created called fastd. It is faster than OpenVPN. But we still had the context switch bottleneck. Therefore I wrote a hacky patch for fastd to utilize io_uring. With that the context switch bottleneck is gone.
Maybe you could adopt this for the OpenVPN userspace version to reach a performance similar to the kernel module:
The 5.3 support itself already involves multiple backports, as the DCO code is designed to work against the latest kernel. Going further back is far more difficult. For instance there are IPv6-related networking stack changes around 5.1-5.3 that cannot be easily worked around if one wanted to go even further back with kernel support.Ok, I just thought their README was implying that it could be backported to older kernels.
Kernel version is determined by the SoC manufacturer (Broadcom in this case). They don`t upgrade kernels, once a platform is launched, it stays on that kernel.
The current newest Broadcom platform used by the recent Pro models is based on kernel 4.19.
What do you think is the reasoning behind never updating the kernel? Seems like it would be beneficial in terms of security, performance and features, no? Disclaimer: I'm just curious, but know none of this.No. As I said, the newest routers use 4.19, and the DCO module requires 5.3.
It may be the later kernels consume more resources and also may not offer any real advantages in the limited use case of a wifi router.What do you think is the reasoning behind never updating the kernel? Seems like it would be beneficial in terms of security, performance and features, no? Disclaimer: I'm just curious, but know none of this.
This is the norm in the embedded device space, same thing with Android phones - your phone will never get a kernel upgrade throughout its lifecycle. My current smartphone has an older kernel version than my router. Main reason is probably it would require some extensive work with drivers, sometimes major changes may be necessary with the drivers, having to revalidate compatibility, etc... Plus afterward you have all the potential userspace content that may also require updates (like iptables), which once again may break things.What do you think is the reasoning behind never updating the kernel?
No, as a new kernel may introduce new issues. Backporting security fixes is the safest route there. This is why products tend to use LTS kernel releases.Seems like it would be beneficial in terms of security
It's interesting that Apple and Microsoft always update their kernels in their major updates, even though these are very different systems, because one of them has full control over the hardware and software they own, and the other is compatible with old drivers.This is the norm in the embedded device space, same thing with Android phones - your phone will never get a kernel upgrade throughout its lifecycle. My current smartphone has an older kernel version than my router. Main reason is probably it would require some extensive work with drivers, sometimes major changes may be necessary with the drivers, having to revalidate compatibility, etc... Plus afterward you have all the potential userspace content that may also require updates (like iptables), which once again may break things.
Yet it is the model that most closely matches the router market, where you have a company that develops the SOC and its SDK, and third parties that develop the hardware and the operating system, use that SOC with its related SDK, and implement the rest of the software stack around it.Android is not a good example
Google is building a set of specifications like Microsoft has done. With GKI 2.0 in the future we will be able to upgrade the kernel independently. It's a long way off, at least until Android 15, but it's already under development.Yet it is the model that most closely matches the router market, where you have a company that develops the SOC and its SDK, and third parties that develop the hardware and the operating system, use that SOC with its related SDK, and implement the rest of the software stack around it.
Apple controls everything from top to bottom, and Microsoft develops APIs specifically to allow easier third party integration with their drivers. And when Microsoft changes that API, they tend to still support the old API for quite some time. Things like WDDM and NDIS are why you can get a new major Windows release and generally still be able to reuse existing drivers. This wasn't always the case however, Windows XP and Vista both required new drivers to work properly.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!