Subject: Re: Small MTU and TCP MSS
To: Paulo Alexandre Pinto Pires <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 05/11/2002 08:26:11
In message <3CDCA35F.6A278959@ppires.org>, Paulo Alexandre Pinto Pires writes:
>I have a setup where a workstation (NetBSD/i386 1.5ZC) is behind a
>firewall/router (NetBSD/i386 1.5U) with a short (1400 octets) link to
>the Internet. I already detected that there is a blackhole router in
>the path to some locations, and that causes trouble in some situations.
>Playing with the system, I was able to tune TCP segment size on output
>traffic, using "route change default -mtu 1400" at the workstation.
>I was then able to see tcpdump's output, showing that no outgoing packet
>had more than 1360 octets of TCP data. However, during initial
>negotiation, TCP MSS was still advertised as 1460. Fiddling with sysctl
>variables net.inet.tcp.mss_ifmtu and net.inet.ip.mtudisc did not change
>this behaviour (as it probably should not, as these varaibles serve to
>Te question is: wouldn't taking MTU data from routing table for
>MSS negotiation at the begining of TCP session be a good thing to do
>(for example, to prevent the stupid router that is "eating" ICMP need
>frag packets that should go to the other end of TCP connections from
>destroying my download streams)? Why isn't this done, and how can
>I work around it? I though of reducing MTU on every interface connected
>to the internal network, but it isn't as easy as it seems, as some
>systems in the network don't seem to allow it, and also because I
>wouldn't like to sacrifice internal network performance if there is a
>I thought of having the NetBSD firewall forcibly fragment large
>segments, but I have read some discussions in NetBSD mailing list
>archives where people condemned this severely. Anyway, is it possible
>to do it with IPF/IPNAT?
>Any clues will be greatly appreciated.
A few months ago, I posted some diffs that let me set the MTU manually.
The archives should have them; if you can't find it, let me know and
I'll dig it up.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com