Bug#587789: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before)
Debian Bug Tracking System schrieb: This is an automatic notification regarding your Bug report which was filed against the linux-image-2.6-686 package: #587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before It has been closed by Ben Hutchings b...@decadent.org.uk. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Ben Hutchings b...@decadent.org.uk by replying to this email. Betreff: Re: Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before Von: Ben Hutchings b...@decadent.org.uk Datum: Fri, 02 Jul 2010 23:28:52 +0100 An: 587789-d...@bugs.debian.org An: 587789-d...@bugs.debian.org On Thu, 2010-07-01 at 18:43 +0200, Daniel Gibson wrote: Package: linux-image-2.6-686 Version: 2.6.26+17+lenny1 Severity: important Hi, Netfilters clamp-mss-to-pmtu (as used in iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) sets MSS in packets that had no MSS set before. The documentation says that TCPMSS sets the MSS option, unconditionally, so this behaviour is correct.Never increase MSS, even when setting it, as doing so The code explicitly says Never increase MSS, even when setting it, as doing so results in problems for hosts that rely on MSS being set correctly. So the MSS option is *not* set unconditionally by --clamp-mss-pmtu. The documentation doesn't explicitly say that, though. To set the MSS to a fixed value --set-mss should be used, I guess. (Explicitly set MSS option to specified value) No MSS set (at a TCP packet) implies the default MSS of 536 as specified by RFC 879. So TCPMSS should in that case either set a MSS of 536 (e.g. before the oldmss newmss check, so if PMTU returned a even lower MSS it is set to that lower value) or at least leave the MSS untouched. The documentation says This target is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed or ICMPv6 Packet Too Big packets. So, if a host (implicitly, in conformance to the RFC) expects packets of default size (MSS 536) and the braindead ISP (or server-/ firewall-admin), blocks the (according to the RFC optional) ICMP Fragmentation Needed packets, the PMTU will not return the correct MTU (of 536) but the MTU of your DSL connection or whatever. TCPMSS is meant to fix exactly this case (blocked ICPM packets), but the author apparently only thought of the case that the server sets a MSS that's to big for the client, so the client must fix that by setting a lower MSS - but not the case that a server expects a smaller MSS (that happens to be the standard MSS) without explicitly saying so. Regards, - Daniel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2e70c1.70...@gmail.com
Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before
Ben Hutchings schrieb: You need to have this argument with the upstream developers, not with me. Ben. Ok. The bug is reported at http://bugzilla.netfilter.org/show_bug.cgi?id=662 - Daniel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2e7a5c.3020...@gmail.com
Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before
Package: linux-image-2.6-686 Version: 2.6.26+17+lenny1 Severity: important Hi, Netfilters clamp-mss-to-pmtu (as used in iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) sets MSS in packets that had no MSS set before. So instead of sending packets of standard TCP MSS 536 Bytes to a host that didn't set a MSS at all, packets with a potentially higher MSS (like 1452 on my DSL connection) will be sent to that host. That might fail if the host only accepts packets with a MSS of 536 (like http://research.microsoft.com). If that host also doesn't send a ICMP fragmentation needed packet (like research.microsoft.com ...) the connection will fail. Clamp-mss-to-pmtu really shouldn't set a MSS if none was set before. RFC 879 says HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS. This means that the standard MTU is 576 and the standard MSS 536 and any server not setting a MSS can expect to only receive packages with a MSS of 536 bytes. If the clamping sets a MSS 536 connections might fail. I stumbled upon this problem in debian bug #541658[1] ([iceweasel] cannot open research.microsoft.com - only worth reading for entertainment purposes) and, after that bug was closed, analysed it in my blog[2] until a friend of mine found out why the page loads when clamping mss to pmtu is disabled or restricted to a range (like with iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu) but doesn't load with simple clamping. His really great and detailed analysation of the problem may be seen at [3]. He also looked into the kernel code (net/netfilter/xt_TCPMSS.c) and found the kind of contradicting comments Never increase MSS, even when setting it, as doing so results in problems for hosts that rely on MSS being set correctly. (line 93) and MSS Option not found ?! add it.. (line 116). So instead of just leaving a packet without MSS option untouched a new MSS, that might be much greater than the default 536, is set, even though the guy who wrote that seemed to be aware that MSS may not be increased. This bug most probably affects all kernel version from at least 2.6.26 (probably also much older versions) up to now. It seems like also some hardware-routers that probably use Linux are affected. Cheers, - Daniel -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6-686 depends on: ii linux-image-2.6.26-2-686 2.6.26-24 Linux 2.6.26 image on PPro/Celeron linux-image-2.6-686 recommends no packages. linux-image-2.6-686 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100701164335.20812.29648.report...@portroyal.horst.lan
Bug#587789: linux-image-2.6-686: netfilters clamp-mss-to-pmtu sets bad MSS when non was set before
Daniel Gibson wrote: Hi, Netfilters clamp-mss-to-pmtu (as used in iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) sets MSS in packets that had no MSS set before. So instead of sending packets of standard TCP MSS 536 Bytes to a host that didn't set a MSS at all, packets with a potentially higher MSS (like 1452 on my DSL connection) will be sent to that host. That might fail if the host only accepts packets with a MSS of 536 (like http://research.microsoft.com). If that host also doesn't send a ICMP fragmentation needed packet (like research.microsoft.com ...) the connection will fail. Clamp-mss-to-pmtu really shouldn't set a MSS if none was set before. RFC 879 says HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS. This means that the standard MTU is 576 and the standard MSS 536 and any server not setting a MSS can expect to only receive packages with a MSS of 536 bytes. If the clamping sets a MSS 536 connections might fail. I stumbled upon this problem in debian bug #541658[1] ([iceweasel] cannot open research.microsoft.com - only worth reading for entertainment purposes) and, after that bug was closed, analysed it in my blog[2] until a friend of mine found out why the page loads when clamping mss to pmtu is disabled or restricted to a range (like with iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu) but doesn't load with simple clamping. His really great and detailed analysation of the problem may be seen at [3]. He also looked into the kernel code (net/netfilter/xt_TCPMSS.c) and found the kind of contradicting comments Never increase MSS, even when setting it, as doing so results in problems for hosts that rely on MSS being set correctly. (line 93) and MSS Option not found ?! add it.. (line 116). So instead of just leaving a packet without MSS option untouched a new MSS, that might be much greater than the default 536, is set, even though the guy who wrote that seemed to be aware that MSS may not be increased. This bug most probably affects all kernel version from at least 2.6.26 (probably also much older versions) up to now. It seems like also some hardware-routers that probably use Linux are affected. Due to a bug of reportbug (I started it with reportbug -o /tmp/bug.txt to send the bug from my regular email-programm, but at the end the bug was sent by reportbug anyway) the report was sent prematurely and the links were missing.. [1] original bug report for iceweasel (not too helpful): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541658 [2] my blog entry analysing the bug: http://caedesnotes.wordpress.com/2010/06/30/bug-hunting-browsers-fail-to-load-research-microsoft-com/ [3] blog entry of a friend of mine who found the real cause: http://carnivore.it/2010/07/01/research.microsoft.com_-_mss_of_536_bytes Cheers, - Daniel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2cc777.80...@gmail.com
