netdev - Re: IPv6 path MTU discovery broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Oct 2013 05:09:10 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	"Steinar H. Gunderson" <sgunderson@...foot.com>,
	netdev@...r.kernel.org, edumazet@...gle.com, fan.du@...driver.com
Subject: Re: IPv6 path MTU discovery broken

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:
> > 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@...driver.com>
> 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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html