On Mon, Oct 07, 2013 at 03:52:52AM +0200, Hannes Frederic Sowa wrote:

On Sun, Oct 06, 2013 at 02:06:12PM +0200, Steinar H. Gunderson wrote:

quoted

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

Hm, this actually went in in 3.12, so a bit too late for things to start
failing in 3.11.

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.

Seems fine.

Could you try to check (with e.g. nstat) if any of the following counters
change if the icmp messages hit the host?

TcpExtOutOfWindowIcmps
Icmp6InErrors
TcpExtTCPMinTTLDrop
TcpExtListenDrops

Thanks,

  Hannes