[Openswan dev] commit b676ce2855f645f1bcaabb643eccfb580e60e3d2

[Paul Wouters]

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