The two possible approaches that have been suggested are:
1. Use the sadb_x_policy_reserved2 field of struct sadb_x_policy to indicate the priority.
2. Use the SADB_X_SPDSETIDX message to do this by defining a new message format that includes the priority (and optionally an interface index as well since this is also supported by the XFRM interface).
Are there opinions on which approach is preferrable? Is there a reason why the reserved2 field should not be used? Also, is SADB_X_SPDSETIDX intended to insert a policy or change the location of an existing one? Currently messages of this type just use pfkey_spdadd, so it seems that this message type could be used as an alternate way of inserting SPD entries when the priority and interface index are desired.
Aidas Kasparas wrote:
John Williams Floroiu wrote:
hi,
here are a few comments I have on xfrm:
1. when a SPD entry is added (see "pfkey_spdadd"), xp->selector.family isn't set accordingly. therefore when making a netlink XFRM_MSG_DELPOLICY or XFRM_MSG_GETPOLICY call this information is completely missing because (unlike "xfrm_policy") "xfrm_userpolicy_info" has no "family" member. as a result the selector sent to the kernel must have "family" set to 0, otherwise the match will fail.
the mega patch that fixes this would look like:
--- net/key/af_key.c.orig 2004-03-23 15:39:14.000000000 +0100
+++ net/key/af_key.c 2004-03-23 18:56:43.000000000 +0100
@@ -1863,6 +1863,7 @@
err = -EINVAL;
goto out;
}
+ xp->selector.family = xp->family;
xp->selector.prefixlen_s = sa->sadb_address_prefixlen;
xp->selector.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto);
xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port;
At ipsec-tools-devel list poeple find a need for patch like this. Yet it would be very helpfull, if designer of this code could clarify:
1) why two family fields (one in policy, another in selector) are needed;
2) how they differs;
3) how they supposed to be filled.
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
