[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#587789: closed by Ben Hutchings <ben@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 <ben@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 <ben@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 <ben@decadent.org.uk>
Datum:
Fri, 02 Jul 2010 23:28:52 +0100
An:
587789-done@bugs.debian.org

An:
587789-done@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
Reply to: