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
| ||
|
Message-ID: <20120716105546.14a6490d@vostro> Date: Mon, 16 Jul 2012 10:55:46 +0300 From: Timo Teras <timo.teras@....fi> To: Steffen Klassert <steffen.klassert@...unet.com> Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: iptables CLAMP MSS to PMTU not working? On Mon, 16 Jul 2012 09:23:05 +0200 Steffen Klassert <steffen.klassert@...unet.com> wrote: > On Mon, Jul 16, 2012 at 09:20:58AM +0300, Timo Teras wrote: > > On Mon, 16 Jul 2012 08:49:46 +0300 Timo Teras <timo.teras@....fi> > > wrote: > > > > > Looking at the changelog, this would likely be side effect of: > > > > > > commit 261663b0ee2ee8e3947f4c11c1a08be18cd2cea1 > > > Author: Steffen Klassert <steffen.klassert@...unet.com> > > > Date: Wed Nov 23 02:14:50 2011 +0000 > > > > > > ipv4: Don't use the cached pmtu informations for input routes > > > > > > At least from performance side, it would be better if CLAMPMSS to > > > PMTU would clamp to the learned, cached mtu. > > > > Actually, this is worse. Since XFRM is ignored - it breaks > > fragmentation for IPsec targets. > > > > Could this be reverted? > > I did this patch to avoid to propagate learned PMTU informations. > It restores the behaviour we had before we moved the PMTU informations > to the inetpeer. Unfortunately CLAMPMSS really wants to have the PMTU > informations of an input route, which is not possible any more after > this patch. > > Anyway, this patch seems to be obsolete in the net-next tree, as > the cached pmtu informations are back in the route. So we should > remove the check for an output route from ipv4_mtu() in the net-next > tree. This should bring CLAMPMSS back to work, at least for upcoming > kernel versions. Right, saw those commits. But before net-next hits release, I'd really need a fix for 3.3/3.4/3.5. Non-working fragmentation with IPsec, and this CLAMPMSS thingy are an upgrade stopper for me. Would it be safe to just revert this commit, with the side-effect of exposing cached pmtu too agressively? Or would it be better to try to backport the relevant changes of moving pmtu back to route table? -- 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
Powered by blists - more mailing lists