Subject: Re: fragmentation by NetBSD routers vs. reassembly on other systems....
To: NetBSD Networking Technical Discussion List <email@example.com>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 09/02/2000 18:07:08
Date: Sat, 2 Sep 2000 02:46:30 -0400 (EDT)
From: firstname.lastname@example.org (Greg A. Woods)
| The proof was clearly visible in the
| evidence collected by actual experimentation.
I have no idea what you have been experimenting with, but...
lavender$ sysctl net.inet.tcp.mssdflt
net.inet.tcp.mssdflt = 512
lavender$ telnet cvs.netbsd.org
telnet: Unable to connect to remote host: Connection refused
17:58:50.397583 126.96.36.199.65489 > 188.8.131.52.23: S 845201410:845201410(0) win 16384 <mss 1460,[|tcp]>
17:58:50.917854 184.108.40.206.23 > 220.127.116.11.65489: R 0:0(0) ack 845201411 win 0 (DF)
Note the advertised MSS, and its relationship with the net.inet.tcp.mssdflt
(18.104.22.168 is lavender). Clearly it is not on the same net as
cvs.netbsd.org. (That the telnet attempt was refused is no surprise).
I know - I also acted without thinking, and tried fiddling with that when
I was experiencing a problem with a host that had broken PMTU discovery
(from home, I use a very low MTU) - I thought if I set the MSS real low,
I could cause the remote host to send small packets, and its broken PMTU
discovery would stop bothering me. And I expect it would have, except
that net.inet.tcp.mssdflt doesn't do that. It does just what jhawk said
it does. I read the code...