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

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

 



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 netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux