On Mon, 21 Jul 2003 04:12:44 +0400 (MSD) kuznet@ms2.inr.ac.ru wrote: > I think this is OK. Kernel does not generate reqids itself, so it > is user responsibility to generate 16bit ones when pfkey is in use. > Well, I would prefer that pfkey users felt something wrong with > such reqids, but it is not really necessary. > > Maybe, to return 0xFFFF, not low 16 bits? I do not know. It then means that 0xFFFF has special meaning and that incoming pfkey requests trying to use this value as req_iq in some request must fail. All of this means that, on machine using many IPSEC rules, pfkey and xfrm simply do not interoperate at all. Actually, looking at how things like racoon use this reqid there in ipsecrequest, it always sets this to zero when passing an ipsecrequest into the kernel, therefore making kernel allocate unique value. Hmmm, maybe it is safe to change this to __u32, but we must also not forget to update net/key/af_key.c:gen_reqid() and IPSEC_MANUAL_REQID_MAX etc. Thoughts? - : 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
