On Mon, Dec 9, 2024 at 6:48 PM Antonio Quartulli antonio@openvpn.net wrote: [...]
+/**
- ovpn_nl_peer_modify - modify the peer attributes according to the incoming msg
- @peer: the peer to modify
- @info: generic netlink info from the user request
- @attrs: the attributes from the user request
- Return: a negative error code in case of failure, 0 on success or 1 on
success and the VPN IPs have been modified (requires rehashing in MP
mode)
- */
+static int ovpn_nl_peer_modify(struct ovpn_peer *peer, struct genl_info *info,
struct nlattr **attrs)
+{
struct sockaddr_storage ss = {};
struct ovpn_socket *ovpn_sock;
u32 sockfd, interv, timeout;
struct socket *sock = NULL;
u8 *local_ip = NULL;
bool rehash = false;
int ret;
if (attrs[OVPN_A_PEER_SOCKET]) {
Similar to link attributes in other tunnel drivers (e.g. IFLA_GRE_LINK, IFLA_GRE_FWMARK), user-supplied sockets could have sockopts (e.g. oif, fwmark, TOS). Since some of them may affect encapsulation and routing decision, which are supported in datapath? And do we need some validation here?
[...]
+static int ovpn_nl_send_peer(struct sk_buff *skb, const struct genl_info *info,
const struct ovpn_peer *peer, u32 portid, u32 seq,
int flags)
+{
const struct ovpn_bind *bind;
struct nlattr *attr;
void *hdr;
hdr = genlmsg_put(skb, portid, seq, &ovpn_nl_family, flags,
OVPN_CMD_PEER_GET);
if (!hdr)
return -ENOBUFS;
attr = nla_nest_start(skb, OVPN_A_PEER);
if (!attr)
goto err;
if (nla_put_u32(skb, OVPN_A_PEER_ID, peer->id))
goto err;
I think it would be helpful to include the netns ID and supported sockopts of the peer socket in peer info message.