>From: Joy Latten <[EMAIL PROTECTED]>
>Date: Mon, 05 Feb 2007 14:53:39 -0600
>
>> I can run some tests with this patch and report any results...
>
>Please check out the two most recent patches I posted:
>
>1) Updated core patch with ipv6 side added.
>2) Fix for thinko noticed by Venkat.
I have been testing this a lot in the lspp kernel.
Plan to test also in upstream kernel.
I am seeing a second ACQUIRE occur while establishing the SAs.
My scenario:
My policy states to use both the ESP and AH protocols (may not
make much sense but this was for testing purposes). I get double
SAs with only difference being SPI.
Here is what I see happening...
1. Trigger first ACQUIRE via ping or netperf.
2. xfrm_lookup() calls xfrm_tmpl_resolv() who calls xfrm_state_find().
First time around, we need to establish SA, so a minimal SA
get allocated and put in SAD, timer is set for the minimal SA
to be ACQUIRED and km_query() gets called.
3. xfrm_tmpl_resolv() returns -EAGAIN causing add_wait_queue(&km_waitq, &wait)
and proceeding code to get called waiting for SA to be established.
As long as the minimal SA with XFRM_STATE_ACQUIRE is in SAD,
we keep waiting...
4. First set of SAs (one for AH and ESP) for IN direction get inserted in SAD.
5. Around the time the set of SAs for OUT direction are to be
inserted into SAD, I see another ACQUIRE happening.
I have not yet figured out where this second ACQUIRE comes from
and why it happens. As long as the minimal SA or set of valid outgoing
SAs exist in SAD, an ACQUIRE should not happen.
The minimal SA does not get removed from the SAD until the set
of SAs for OUT get added and the xfrm_state_lock
released. And the lock pretty much guarantees no one else can step
through the SAD until after new SAs are being added...
and if someone gets the lock to step though SAD before OUT SAs
are added, minimal SA is still there...
6. Since this second ACQUIRE was able to happen, result is identical
sets of SAs for the traffic stream. SPIs are only difference.
7. Noticed something while pasting log info below.
Perhaps when outgoing AH SA is added, wake_up(&km_waitq) gets called,
lock released, and minimal SA deleted (xfrm_state_add()),
xfrm_tmpl_resolv() is called and it looks first for the outgoing
ESP SA. Since it is not there yet and no minimal SA, then km_query()
results in an ACQUIRE just before the outgoing ESP SA gets added.
It would explain why I only see it when both ESP and AH are specified...
that is if I am thinking correctly...
Regards,
Joy Latten
>From my log file:
Mar 5 19:10:02 racoon: INFO: initiate new phase 2 negotiation:
9.3.192.210[500]<=>9.3.189.55[500]
Mar 5 19:10:03 racoon: INFO: IPsec-SA established: AH/Transport
9.3.189.55[0]->9.3.192.210[0] spi=137942922(0x838d78a)
Mar 5 19:10:03 racoon: INFO: IPsec-SA established: ESP/Transport
9.3.189.55[0]->9.3.192.210[0] spi=244321490(0xe900cd2)
Mar 5 19:10:03 racoon: INFO: IPsec-SA established: AH/Transport
9.3.192.210[0]->9.3.189.55[0] spi=38721750(0x24ed8d6)
Mar 5 19:10:03 racoon: INFO: initiate new phase 2 negotiation:
9.3.192.210[500]<=>9.3.189.55[500]
Mar 5 19:10:03 racoon: INFO: IPsec-SA established: ESP/Transport
9.3.192.210[0]->9.3.189.55[0] spi=265079770(0xfcccbda)
Mar 5 19:10:05 racoon: INFO: IPsec-SA established: AH/Transport
9.3.189.55[0]->9.3.192.210[0] spi=108627618(0x67986a2)
Mar 5 19:10:05 racoon: INFO: IPsec-SA established: ESP/Transport
9.3.189.55[0]->9.3.192.210[0] spi=182973856(0xae7f5a0)
Mar 5 19:10:05 racoon: INFO: IPsec-SA established: AH/Transport
9.3.192.210[0]->9.3.189.55[0] spi=58486297(0x37c6e19)
Mar 5 19:10:05 racoon: INFO: IPsec-SA established: ESP/Transport
9.3.192.210[0]->9.3.189.55[0] spi=268295215(0xffddc2f)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
