Skip to content

Commit

Permalink
pluto: xfrmi_if_id use yn_no instead of 0
Browse files Browse the repository at this point in the history 
using enum constant is better. Can also help we decide
yn_no is UINT32_MAX
  • Loading branch information
@antonyantony
antonyantony committed Sep 17, 2020
1 parent 799dfa9 commit 092475c
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion programs/pluto/kernel_xfrm.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1545,7 +1545,7 @@ static bool netlink_add_sa(const struct kernel_sa *sa, bool replace)
attr = (struct rtattr *)((char *)attr + attr->rta_len);
}

if (sa->xfrm_if_id > 0) {
if (sa->xfrm_if_id != yn_no) {
#ifdef USE_XFRM_INTERFACE
dbg("%s netlink: XFRMA_IF_ID %" PRIu32 " req.n.nlmsg_type=%" PRIu32,
__func__, sa->xfrm_if_id, req.n.nlmsg_type);
Expand Down

1 comment on commit 092475c

@letoams
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you might be mixing up two things.

  1. How to signal the ipsec-interface number in ipsec.conf
  2. Send the if_id from connection to the kernel

For the configuration part, I map UINT_MAX to "disabled" and everything else to their respective integer. This allows someone to configure ipsec-interface=0 to gain an ipsec0 device. This device will not get if_id 0

For the if_id passing, the connection will map ipsec-interface value 0 to the if_id value 16384. And the xfrmi code that maps if_id to interface name maps ipsec0 to if_id 16384 and maps all other if_id's to their respective ipsecXXX name.

So, the yn_no and yn_yes (which I had renamed to yn_dev_yes and yn_dev_no since they cannot be re-used for generic yes/no keywords, only applies to ipsec-interface= values and does not map to if_id / xfrmi_if_id values. Those values are integers only and not an enum of some kind. Specifically, the if_id of UINT_MAX is not treated special.

Please sign in to comment.