|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|
|References:||<1112405144.1096.33.camel@xxxxxxxxxxxxxxxx> <20050402140019.GA13017@xxxxxxxxxxxxxxx> <1112478168.1088.337.camel@xxxxxxxxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1|
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. Regards Patrick
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: take 2 WAS(Re: PATCH: IPSEC xfrm events, Patrick McHardy|
|Next by Date:||[IPSEC]: Protect against BHs in xfrm_user_policy(), Patrick McHardy|
|Previous by Thread:||Re: IPSEC: on behavior of acquire, Thomas Graf|
|Next by Thread:||Re: IPSEC: on behavior of acquire, Aidas Kasparas|
|Indexes:||[Date] [Thread] [Top] [All Lists]|