On Sun, Jul 13, 2003 at 07:58:40AM +0400, kuznet@ms2.inr.ac.ru wrote:
>
> > Since it doesn't make sense to have a wildcard reqid match, the patch
> > can and should be simplified as follows.
>
> Actually, it makes lots of sense. On output wildcard template
> is not permitted to use SA reserved for some policy via reqid.
> But on input it would be something strange.
OK. But are you agreeable at least to the checking of reqid's on input
as seen below?
> > BTW, is there any reason why we don't cater for hardcoded outbound SPIs
> > in xfrm_state_find?
>
> No. pfkey simply did not allow to set a fixed SPI in template,
> so this possibility remained unused. I do not even know, is SPI
> not supposed to be a random number? If so, static SPIs may be
> even illegal. Anyway, KAME's idea with reqid's provides more
> smart and more general replacement.
reqid definitely makes hardcoding SPIs redundant. That is why I'd like
to have it on the input path as well.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--- kernel-source-2.5/net/xfrm/xfrm_policy.c.orig 2003-07-13 10:58:50.000000000 +1000
+++ kernel-source-2.5/net/xfrm/xfrm_policy.c 2003-07-13 10:59:06.000000000 +1000
@@ -860,6 +860,7 @@
{
return x->id.proto == tmpl->id.proto &&
(x->id.spi == tmpl->id.spi || !tmpl->id.spi) &&
+ (x->props.reqid == tmpl->reqid || !tmpl->reqid) &&
x->props.mode == tmpl->mode &&
(tmpl->aalgos & (1<<x->props.aalgo)) &&
!(x->props.mode && xfrm_state_addr_cmp(tmpl, x, family));
