Re: [RFC v2] net: introduce OpenVPN Data Channel Offload (ovpn-dco)

[Sergey Ryazanov]

Hello Stephen,

On Fri, Aug 12, 2022 at 9:44 PM Stephen Hemminger
<stephen@xxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 12 Aug 2022 21:34:33 +0300
> Sergey Ryazanov <ryazanov.s.a@xxxxxxxxx> wrote:
>> What is the purpose of creating and destroying interfaces via RTNL,
>> but performing all other operations using the dedicated netlink
>> protocol?
>>
>> RTNL interface usually implemented for some standalone interface
>> types, e.g. VLAN, GRE, etc. Here we need a userspace application
>> anyway to be able to use the network device to forward traffic, and
>> the module implements the dedicated GENL protocol. So why not just
>> introduce OVPN_CMD_NEW_IFACE and OVPN_CMD_DEL_IFACE commands to the
>> GENL interface? It looks like this will simplify the userspace part by
>> using the single GENL interface for any management operations.
>
> RTNL is netlink. The standard way to create network devices should
> be available with newlink message as in:
>
>  # ip link add dev myvpn type ovpn <options>

If you do not mind, then I would like to say that RTNL is not a
standard way, but a common way to create a virtual network interface.

The RTNL ability to create network devices is very useful for
standalone interface types (VLANs, GRE, etc.). But there are other
types that require much more care to be brought into a usable state.
E.g., WLAN devices can only be managed by GENL. Even L2TP that can be
created with ip(8) actually utilizes the GENL based interface and
completely ignores RTNL.

An OpenVPN network device created with ip-link(8) will remain useless
until the control daemon establishes a connection, negotiates params,
adds a peer, etc. And all these actions should be performed using a
separate GENL interface. I mean that the RTNL support in the OpenVPN
module is a dead-end.

That is why I suggested Antonio to save his time by ignoring the
network interface creation with RTNL and focus on the GENL interface.
Using only the GENL-based interface will also simplify development of
the control daemon. Does this strategy sound reasonable in this
particular context?

--
Sergey