Subject: Re: Small MTU and TCP MSS
To: Paulo Alexandre Pinto Pires <>
From: Steven M. Bellovin <>
List: current-users
Date: 05/11/2002 08:26:11
In message <>, Paulo Alexandre Pinto Pires writes:
>Hello, folks.
>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
>something else).
>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
>reasonable alternative.
>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,
		Full text of "Firewalls" book now at