Herbert Xu wrote:
Hi Andreas:
On Mon, Jan 31, 2005 at 03:40:16PM +0000, Andreas Unterluggauer wrote:
2005-01-31 16:29:58: DEBUG: ===
2005-01-31 16:29:58: DEBUG: get pfkey ADD message
andi: libipsec/pfkey.c, pfkey_check: start (msg->sadb_msg_satype: 3)
2005-01-31 16:29:58: DEBUG: andi: in pfkey.c, pk_recvadd: msg->sadb_msg_seq 2,
msg->sadb_msg_type: ADD
2005-01-31 16:29:58: INFO: IPsec-SA established: ESP/Transport
192.168.2.5->192.168.2.3 spi=103868257(0x630e761)
2005-01-31 16:29:58: DEBUG: ===
Does the machine hang at this point in time? If not, then this is
simply a racoon bug. Although the acquire message carries a policy
with it, it's really only acquiring a single SA. Therefore, only
the SA being acquired should be added with that sequence number.
You're right, but I think there is also kernel misbehaviour here that
is fixed by the patch for __xfrm_state_find_acq_byseq() I sent to Dave
earlier. Andreas, can you try this patch please ?
Regards
Patrick
===== net/xfrm/xfrm_state.c 1.55 vs edited =====
--- 1.55/net/xfrm/xfrm_state.c 2005-03-07 06:23:53 +01:00
+++ edited/net/xfrm/xfrm_state.c 2005-03-08 18:42:13 +01:00
@@ -609,7 +609,7 @@
for (i = 0; i < XFRM_DST_HSIZE; i++) {
list_for_each_entry(x, xfrm_state_bydst+i, bydst) {
- if (x->km.seq == seq) {
+ if (x->km.seq == seq && x->km.state == XFRM_STATE_ACQ) {
xfrm_state_hold(x);
return x;
}
|