[Top] [All Lists]

Re: IPSEC: on behavior of acquire

To: hadi@xxxxxxxxxx
Subject: Re: IPSEC: on behavior of acquire
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Sun, 03 Apr 2005 17:52:26 +0200
Cc: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Masahide NAKAMURA <nakam@xxxxxxxxxxxxxx>, ipsec-tools-devel@xxxxxxxxxxxxxxxxxxxxx, netdev <netdev@xxxxxxxxxxx>, jmorris@xxxxxxxxxx
In-reply-to: <1112478168.1088.337.camel@xxxxxxxxxxxxxxxx>
References: <1112405144.1096.33.camel@xxxxxxxxxxxxxxxx> <20050402140019.GA13017@xxxxxxxxxxxxxxx> <1112478168.1088.337.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1
jamal wrote:
Herbert also mentions something along the same lines in his email. This would make a lot of sense!
Is the state machine going to look something along the same lines as
ARP? i.e incomplete->reachable etc?

Yes, from a bundle POV. In my current approach a single state is
resolved at a time and resolution is driven by XFRM_STATE_ACQ->*
state transitions.

What would be a good code to return when you queue the packet?

It should be transparent, so 0.


<Prev in Thread] Current Thread [Next in Thread>