[Openswan dev] commit b676ce2855f645f1bcaabb643eccfb580e60e3d2 (fwd)

[Paul Wouters]

---------- Forwarded message ----------
Date: Thu, 16 Dec 2010 11:36:34 +0100
From: Harald Jenny <harald at a-little-linux-box.at>
To: Paul Wouters <paul at xelerance.com>
Subject: Re: [Openswan dev] commit b676ce2855f645f1bcaabb643eccfb580e60e3d2

Sorry could you cc the reply to David too? Thanks

On Wed, Dec 15, 2010 at 11:01:28AM -0500, Paul Wouters wrote:
> On Wed, 15 Dec 2010, Harald Jenny wrote:
>
>>>One small totally uneducated comment: eth0 might not be a valid interface
>>>either. Not sure if this would/could break anything, but though I'd mention it
>>>anyway ;-)
>
> That is true. And I did realise that (hence I added it to the comment)
> But it is bound to work better then a non-existing "ipsec0" device when
> using netkey.
>
>>And testing for the new NAT-T code on NETKEY is not needed as there is only the
>>"old" one ;-).
>
> Not true, since the "new" (moved code) code calls xfrm4_udp_encap_rcv()
> in udp.c. Which is located in xfrm4_input.c which is only compiled in
> when setting CONFIG_XFRM. So the code could have been left out of the kernel
> when its intend was to use KLIPS and not NETKEY/XFRM.
>
> In 2.6.21 and earlier, the encap function would be in af_key (NETKEY) which we
> could not load because it would also hook the ESP/AH protocols (which KLIPS
> would need). In 2.6.22 this was split of into xfrm_input.c (when adding the
> UDP_ENCAP_L2TPINUDP support for CONFIG_L2TPOPPP)
>
> I realise using "eth0" is not fool proof. I'm open to suggestions. Since the
> open socket was returned in that function, it seemed unwise to use "lo".
>
> One would have to check more closely what the open socket returned is used for.
>
> Paul