netdev - Re: [PATCH] ipv4: icmp: Fix pMTU handling for rare case

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.10.1407011912440.5997@tabini.allcutt.me.uk>
Date:	Tue, 1 Jul 2014 19:50:15 +0100 (BST)
From:	Edward Allcutt <edward.allcutt@...nmarket.com>
To:	David Miller <davem@...emloft.net>
cc:	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ipv4: icmp: Fix pMTU handling for rare case

On Tue, 1 Jul 2014, David Miller wrote:
>> If it helps any, I've been running several production machines with
>> this patch for just about a year now (mostly running 3.10 stable
>> series).
>
> I guess if OpenBSD can wait more than 2 decades to implement proper
> path mtu handling, you can wait a year to post this bug fix :-)

Sorry about that. :-/ Some of the systems on the other end of tunnels are 
now starting to run distro kernels with this bug. I can't always convince 
them to rebuild with a patch.. I should have gotten around to this sooner.

> I still think the OpenBSD thing can't be intentional, and it's some
> bug they probably want to fix and it should therefore be investigated.
> It means performance of connections going through such machines is
> going to be crap even if I install your patch.

Making newer versions behave better won't help all the existing 
deployments. Linux should be able to cope even if it's not optimal.

The performance impact of using minimum packet size vs. optimal sizing is 
that you end up sending a bit under three times the number of packets. At 
worst. It's not ideal but it's far less bad than stalling indefinitely.

The patch won't affect performance of the normal case where more useful 
ICMP errors are received.

I did look at trying to reintroduce the original function which guessed 
the next smallest value. However since the routing cache has gone away I 
don't think there's anywhere to find out the size of previously sent 
packets without interrogating the upper protocol.. so handing the upper 
protocol the 0 value and letting it handle it seems the best approach.

Now perhaps the plateau-finding function should be reintroduced for tcp 
and other stream-oriented protocols. Is "it could be done better" enough 
reason to reject a patch that mitigates a real regression?

Is there another reason you dislike this approach?

-- 
Edward Allcutt
Senior Systems Engineer
OpenMarket | http://www.openmarket.com/
--
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