[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190716135646.GE2622@TopQuark.net>
Date: Tue, 16 Jul 2019 09:56:46 -0400
From: Paul Donohue <linux-kernel@...lSD.com>
To: David Ahern <dsahern@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
netdev@...r.kernel.org
Subject: Re: IPv6 L2TP issues related to 93531c67
On Mon, Jul 15, 2019 at 12:55:48PM -0600, David Ahern wrote:
> As an FYI, gmail thinks your emails are spam.
Ugh. Thanks for letting me know. I'll look into it.
> On 7/15/19 10:18 AM, Paul Donohue wrote:
> > Reverting commit 93531c6743157d7e8c5792f8ed1a57641149d62c (identified by bisection) fixes this issue.
> That commit can not be reverted. It is a foundational piece for a lot of
> other changes. Did you mean the commit before it works and this commit
> fails?
Sorry, yes, I meant the commit before it works, and this one fails. I did not try reverting this commit on a more recent kernel.
> > It is not obvious to me how commit 93531c6743157d7e8c5792f8ed1a57641149d62c causes this issue, or how it should be fixed. Could someone take a look and point me in the right direction for further troubleshooting?
> Let's get a complete example that demonstrates the problem, and I can go
> from there. Can you take the attached script and update it so that it
> reflects the problem you are reporting? That script works on latest
> kernel as well as 4.14.133. It uses network namespaces for 2 hosts with
> a router between them.
>
> Also, check the return of the fib lookups using:
> perf record -e fib6:* -a
> <run test, ctrl-c on the record>
> perf script
>
> Checkout the fib lookup parameters and result. Do they look correct to
> you for your setup?
Unfortunately, I have a fairly complicated setup, so it took me a while to figure out which pieces were relevant ... But I think I've finally got it. The missing piece was IPsec.
After establishing an IPsec tunnel to carry the L2TP traffic, the first L2TP packet through the IPsec tunnel permanently breaks the associated L2TP tunnel. Tearing down the IPsec tunnel does not restore functionality of the L2TP tunnel - I have to tear down and re-create the L2TP tunnel before it will work again. In my real-world use case, I have two L2TP tunnels running over the same IPsec tunnel, and the first L2TP tunnel to send a packet after IPsec is established gets permanently broken, while the other L2TP tunnel works fine.
I've attached a modified version of the script which demonstrates this issue.
Thank you!
-Paul
Download attachment "l2tp.sh" of type "application/x-sh" (4825 bytes)
Powered by blists - more mailing lists