netdev - Re: iptables CLAMP MSS to PMTU not working?

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, 16 Jul 2012 08:49:46 +0300
From:	Timo Teras <timo.teras@....fi>
To:	Steffen Klassert <steffen.klassert@...unet.com>
Cc:	netdev@...r.kernel.org
Subject: Re: iptables CLAMP MSS to PMTU not working?

On Thu, 12 Jul 2012 13:24:19 +0300 Timo Teras <timo.teras@....fi> wrote:

> On Thu, 12 Jul 2012 12:00:21 +0300 Timo Teras <timo.teras@....fi>
> wrote:
> 
> > We recently noticed that CLAMPMSS to path MTU does not seem to be
> > working properly. Most recently tested version is linux-3.3.6 which
> > does not work. linux-2.6.35 works for sure, but I suspect it to have
> > broken somewhere around 3.0'ish with the inetpeer changes.
> > 
> > In my case, the destination is on gre tunnel (that gets routed to
> > Internet over IPsec transport mode).
> > 
> > 'ip route' command verifies that in both boxes the path-MTU is
> > detected properly. That, is on both cases the static route MTU is
> > higher. And after large packets sent, ICMP frag-needed is received
> > and the cache route is updated properly.
> > 
> > On the new kernel, I get info like:
> > # ip route get 10.x.x.x
> > 10.x.x.x via 172.16.y.y dev gre1  src 172.16.z.z 
> >     cache  expires 68sec ipid 0x3153 mtu 1422
> 
> CLAMP MSS sets MSS to 1432. Which implies MTU 1472. This matches the
> gre1 interface MTU:
> 
> 14: gre1: <UP,LOWER_UP> mtu 1472 qdisc noqueue state UNKNOWN 
> 
> So apparently CLAMPMSS is honoring the static route for gre1, instead
> of the cached pmtu route.
> 
> > And the older kernel:
> > # ip route get 10.x.x.x
> > 10.x.x.x via 172.16.y.y dev gre1  src 172.16.z.z 
> >     cache  expires 595sec ipid 0xd241 mtu 1422 advmss 1432 hoplimit
> > 64
> > 
> > For some reason, iptables CLAMPMSS seems to set incorrect MSS for
> > this route (or maybe it's using the static route instead?).
> 
> And in this case MSS is set to 1382. That is, it's properly calculated
> from the path MTU (1422-40=1382). I would expect the advmss of the
> cached route to get updated on the TCP connects on the older kernels
> (the above paste is after pinging with large packets and no TCP
> connection done for the cached entry).

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.
--
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