Re: IPv6 path MTU discovery broken

[Hannes Frederic Sowa <hannes@stressinduktion.org>]

On Sun, Oct 06, 2013 at 02:06:12PM +0200, Steinar H. Gunderson wrote:
> On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
> >> So the “packet too big” packets really look like they're being ignored.
> >> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
> >> seems to increase.
> >> 
> >> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
> >> while the default route is to a link-local address? (An RPF issue?) This used
> >> to work (although it was often flaky for me) in 3.10 and before. I can't
> >> easily bisect, though, as I don't boot this machine too often.
> > This looks like a bug and should definitely get fixed. There should be
> > no RPF issue. May I have a look at your /proc/net/ipv6_route?
> 
> It started again, so now I could capture what you asked for:
> 
> pannekake:~> cat /proc/net/ipv6_route 
> 2001067c00a400037c4d9ae8ab73230f 80 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000000 00000001 00000137 01000023     eth0

This one does look like the most probable route which could have the problem.
It has a RTF_MODIFIED flag indicating it received a pmtu update.

Did you take the snapshot while the tcp connection was hanging? We normally
take 2 references to the rt6_info while the tcp connection is running, this
oddly only has one (but got used a lot). But doing a judgement on the
reference count is imprecise.

If you write that this got worse in recent kernels I suspect commit

commit ca4c3fc24e293719fe7410c4e63da9b6bc633b83
Author: fan.du <fan.du@windriver.com>
Date:   Tue Jul 30 08:33:53 2013 +0800

    net: split rt_genid for ipv4 and ipv6


The commit itself is fine, we may have a problem in our dst check logic
or do not bump rt6_genid at some point? If this is the case I might have
an idea how to reproduce the problem.

Greetings,

  Hannes