In message <3CDCA35F.6A278959@ppires.org>, 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, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com