Re: [PATCH net-next 5/8] ovpn: add support for asymmetric peer IDs

[Sabrina Dubroca <sd@queasysnail.net>]

2025-11-13, 15:12:41 +0100, Antonio Quartulli wrote:
> Hi Sabrina,
> 
> On 13/11/2025 14:58, Sabrina Dubroca wrote:
> > 2025-11-11, 22:47:38 +0100, Antonio Quartulli wrote:
> > > From: Ralf Lici <ralf@mandelbit.com>
> > > 
> > > In order to support the multipeer architecture, upon connection setup
> > > each side of a tunnel advertises a unique ID that the other side must
> > > include in packets sent to them. Therefore when transmitting a packet, a
> > > peer inserts the recipient's advertised ID for that specific tunnel into
> > > the peer ID field. When receiving a packet, a peer expects to find its
> > > own unique receive ID for that specific tunnel in the peer ID field.
> > > 
> > > Add support for the TX peer ID and embed it into transmitting packets.
> > > If no TX peer ID is specified, fallback to using the same peer ID both
> > > for RX and TX in order to be compatible with the non-multipeer compliant
> > > peers.
> > > 
> > > Signed-off-by: Ralf Lici <ralf@mandelbit.com>
> > > Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
> > > ---
> > >   Documentation/netlink/specs/ovpn.yaml | 17 ++++++++++++++++-
> > >   drivers/net/ovpn/crypto_aead.c        |  2 +-
> > >   drivers/net/ovpn/netlink-gen.c        | 13 ++++++++++---
> > >   drivers/net/ovpn/netlink-gen.h        |  6 +++---
> > >   drivers/net/ovpn/netlink.c            | 14 ++++++++++++--
> > >   drivers/net/ovpn/peer.c               |  4 ++++
> > >   drivers/net/ovpn/peer.h               |  4 +++-
> > >   include/uapi/linux/ovpn.h             |  1 +
> > >   8 files changed, 50 insertions(+), 11 deletions(-)
> > 
> > The patch looks ok, but shouldn't there be a selftest for this
> > feature, and a few others in this series (bound device/address, maybe
> > the RPF patch as well)?
> 
> selftests were indeed extended to check for this feature (and others).
> However, since these extensions required some restructuring, I preferred to
> keep all selftests patches for a second PR.
> 
> It's obviously always better to have feature+test shipped together, but the
> restructuring on the selftests may require a discussion on its own,
> therefore I decided to go this way.
> 
> I hope it makes sense.

Ok, not ideal but I can live with that.

Then for this patch:
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>

-- 
Sabrina