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.

--
        Pappires

... Qui habet aurem audiat quid Spiritus dicat ecclesiis.