[Openswan dev] NAT-T patch

Paul Wouters paul at xelerance.com
Wed May 20 21:53:00 EDT 2009

On Thu, 21 May 2009, David McCullough wrote:

> There looks to be all the kernel level support for L2TP in 2.6.29,  so is
> L2TP using it's own drivers or the kernel ones ?  Is this even that same
> L2TP stack we are talking about or a user mode stack of sorts ?

I am not sure what you mean with "drivers" here. Normally l2tp is pure
userspace. l2tp packets can be control packets (like IKE) or data packets
(like ESP). The kernel l2tp driver (as far as I know) just checks to see
if the current l2tp packet is a data packet. If so, it just removes the l2tp
header and processing continues in the kernel (of a ppp packet i guess).
This avoids the pushing l2tp to userland, decapsulate and then push it to ppp.

> If the desire is to get KLIPS to interact more nicely with L2TP user space,
> and not change NETKEY or the kernel L2TP code,  then I guess we could do
> something there that won't require kernel patches.  After all,  after ipsec
> is done we could easily see that we have an L2TP packet.

Exactly, though I think we should be able to just call (or rely?) on the
current l2tp kernel module? Eg can't we punt the decrypted l2tp packet to
the l2tp decaps kernel hook function?

The xl2tpd daemon supports the l2tp kernel module, though perhaps only via
an older kernel patch. When the l2tp kernel patch got integrated, it changed
a bit, and I'm not sure if xl2tpd still supports it.

> Sorry, I would like to know more about L2TP

No you don't :)


More information about the Dev mailing list