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:

quoted

quoted

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 [off-list ref]
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