netdev - RE: [PATCH 3/5] netfilter: xt_TCPMSS: Fix violation of RFC879 in absence of MSS option

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] [day] [month] [year] [list]

Date:	Fri, 21 Jun 2013 10:27:18 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...i.de>
To:	Jeff Haran <Jeff.Haran@...rix.com>
cc:	'Rick Jones' <rick.jones2@...com>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	David Laight <David.Laight@...LAB.COM>,
	Phil Oester <kernel@...uxace.com>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH 3/5] netfilter: xt_TCPMSS: Fix violation of RFC879 in
 absence of MSS option

On Tuesday 2013-06-11 20:31, Jeff Haran wrote:
>> > It seems the version of
>> > the DHCP client that came with the new distro honored the DHCP MTU
>> > option, but Comcast was advertising DHCP offers with an MTU of 576.
>>
>> Did your SuSE system send actual TCP MSS options based on the 576
>> byte MTU?

Yes and it makes for horrible performance. In fact, the "Unitymedia"
cable provider in Germany does exactly the same stupid thing, sending
MTU=576 in their DHCP responses, despite the link actually being
capable of MTU 1500 ("capable" as in, not returning a Fragmentation
Needed ICMP). The only way to get around this provider's idiocy is to
manually set MTU=1500 in SUSE's network config, which overrides the
DHCP values. The way it works is probably by way of using the
scripting functions of prominent DHCP and VPN clients (the C programs
only does the network job and otherwise calls /bin/sh-type logic to
actually modify the interface parameters) like dhclient,dhcpcd,vpnc.

>> Presumably then, your system rejected any incoming packet which was
>> larger than the 576 byte MTU it got from the Comcast DHCP server..

The MTU is not used to block incoming packets. That would not make
sense either (because you already have received the packet and
therefore can use it). In fact, TCP-receive-offloading hardware may
even pass to the kernel packets that are larger than both the output
MTU of your own system as well as larger as the output MTU of the
router you got it from.
--
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