Can the old kernel version (4.4.x) not be supported?

[zyp2015]

I cannot compile and pass in the kernel on 4.4.x. I am not a kernel developer and found that ptr_ring is not supported. How to adapt this?

[ordex]

Hi, unfortunately there is no one line fix. The ptr_ring structure is used in multiple parts of the code and cannot be easily replaced. Maybe you could try to "backport" the implementation of ptr_ring so that it can be available to ovpn-dco.

[zyp2015]

Thanks for your reply, I am doing this too, it seems that ptr_ring is a relatively independent module.

[zyp2015]

It is very difficult to port related kernel features. Can ovpn-dco support this kernel version?

[ordex]

@zyp2015 to support an older kernel version, newer features have to be backported and "changes" (i.e. in function names or data structures) have to be worked around. This is what normally makes up the "compat layer".

[zyp2015]

@ordex Is there any detailed information? I want to try this.

[ordex]

@zyp2015 no. you need to attempt compiling, see what's missing and start working with that. What you have done so far is already part of the job: ptr_ring is missing -> backport it in a way that is acceptable so that ovpn-dco can compile on 4.4.

[ordex]

@zyp2015 any specific reason for requiring support of linux-4.4? That is pretty ancient. I can only guess you are stuck with some old/not-updated SDK?

[zyp2015]

@ordex yes,SDK only can be 4.4. From the principle point of view, this kernel module does not depend on openvpn in user space at all? Is that right?

[zyp2015]

@ordex When I first saw this project, I thought that openvpn in user space was responsible for establishing the control channel and negotiating the key, and transmitting the key to ovpn-dco, and ovpn-dco did the encryption and decryption of the data channel.

[cron2]

Hi,

On Mon, Dec 20, 2021 at 05:12:53AM -0800, SuperDay wrote:

@ordex When I first saw this project, I thought that openvpn in user space was responsible for establishing the control channel and negotiating the key, and transmitting the key to ovpn-dco, and ovpn-dco did the encryption and decryption of the data channel.

This is correct.

OpenVPN in userspace does not need a "modern kernel", though - so the "do not use ancient kernel" issue comes from the DCO module.

gert

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***

[zyp2015]

@cron2 @ordex ovpn-dco should cooperate with openvpn in user space, so that it can significantly improve the performance of openvpn on embedded devices such as routers.

[cron2]

Hi,

On Mon, Dec 20, 2021 at 05:22:56AM -0800, SuperDay wrote:

@cron2 @ordex ovpn-dco should cooperate with openvpn in user space, so that it can significantly improve the performance of openvpn on embedded devices such as routers.

This is what it does. Kernel does things that need to be fast, and userland handles things that are complex (like, all the TLS stuff, parsing config, running scripts, ...)

gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***

[zyp2015]

I am running openvpn on the router now, the throughput rate is very low, even only 1/5 of ipsec, using the same encryption and decryption algorithm.

[cron2]

Hi,

On Mon, Dec 20, 2021 at 05:29:33AM -0800, SuperDay wrote:

I am running openvpn on the router now, the throughput rate is very low, even only 1/5 of ipsec, using the same encryption and decryption algorithm.

This is why we have added DCO.

gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***

[zyp2015]

What technology does DCO use? I read the code, not too clear, not familiar with the kernel, but understand a little bit. Will netdevice be created in DCO?

[zyp2015]

Or is there any technical documentation? Urgently want to understand.

[ordex]

@zyp2015 this is out of the scope of this bug tracker. For further discussions, please start a thread on the openvpn-devel mailing list: https://sourceforge.net/projects/openvpn/lists/openvpn-devel

In a nutshell: ovpn-dco is a device driver - similarly to what the tun module does, it allows the system to create netdevices of type 'ovpn-dco'. The device can then be driven via netlink (this is what openvpn userspace is expected to do).

Further documentation will be released, but for more discussion, please join the mailing list or IRC.

[zyp2015]

OK，Then back to this question. I can now compile and pass on 4.4.

[ordex]

@zyp2015 how about sending a patch to the mailing list? Thanks a lot!

[zyp2015]

It doesn't work for the time being. I compiled it after removing the netlink, and part of the modification involved the kernel code. Now it is only compiled and cannot be used.

[zyp2015]

4.4 Many macro definitions about netlink are undefined, which is very troublesome. I now consider using debugfs to replace netlink. I looked at the code during the modification, This kernel module has nothing to do with the current openvpn, does it? They are currently unable to cooperate?

[ordex]

@zyp2015 Please read the previous messages sent to the mailing list regarding ovpn-dco.

This kernel module is supported by the OpenVPN3-Linux client, while support for OpenVPN2.x is currently work in progress in this branch: https://github.com/ordex/openvpn/tree/dco

[cron2]

Hi,

On Tue, Dec 21, 2021 at 01:40:01AM -0800, SuperDay wrote:

4.4 Many macro definitions about netlink are undefined, which is very troublesome. I now consider using debugfs to replace netlink.

Going to debugfs is not a good way forward - we will not implement the userland part for "netlink and debugfs", so the kernel side needs to stay on netlink.

If the defines are not there, you need to see what they do in recent kernels, and bring them back.

gert

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***

[zyp2015]

You are right.