setting the other end's TCP segment size

[Nikos Vassiliadis]

On Monday 04 August 2008 00:16:54 perryh at pluto.rain.com wrote:
> > > >> Is there a simple way for a FreeBSD system to cause its
> > > >> peer to use a transmit segment size of, say, 640 bytes --
> > > >> so that the peer will never try to send a packet larger
> > > >> than that?
> > > >>
> > > >> I'm trying to get around a network packet-size problem.
> > > >> In case it matters, the other end is SunOS 4.1.1 on a
> > > >> sun3, and I've been unable to find a way to limit its
> > > >> packet size directly.
>
> ...
>
> > > > Each tcp conversation can have it's own size set along
> > > > with a bunch of other params.
> > >
> > > Good point.  The TCP_MAXSEG can reduce the maximum segment
> > > size for a single TCP connection to something smaller than
> > > the interface MTU :)
>
> That would be OK, provided I could somehow arrange for it to apply
> to all conversations with this particular destination (which is
> what the next item seems to do :)
>
> > Just adding that MTU can be set per destination with the help
> > of route(8) and the -mtu modifier.
>
> That would be better than setting the local mtu -- which has been
> causing other problems although it takes care of the original --
> and it is a better match to the physical situation.  (The culprit
> is neither the Sun nor the FreeBSD system, but the physical link
> between the Sun and the hub.)
>
> What I haven't been able to come up with is a way of making such
> a setting permanent.  If I've communicated with the Sun recently
> enough, "netstat -r -W" reports a line like this (some spaces
> removed, for length, and I've no longer got xl0's mtu set low)
>
> Destination   Gateway           Flags Refs Use  Mtu Netif Expire
> 192.168.200.3 08:00:20:00:a7:a6 UHLW     1  34 1500   xl0   1184
>
> Now if I do
>
> # route change 192.168.200.3 -lock -mtu 640
>
> the mtu column changes to 640 and it works fine, but only until
> the routing entry expires.  Adding -static makes no difference
> -- the entry still expires and loses the mtu specification.
>
> I've been unable to come up with a route command that will *create*
> an entry like that (vs modifying an existing one), nor that will
> transform a transient entry into a permanent one.

Yes, it's the interaction of ARP and the routing subsystem.
I am sure there is a shorter way for doing this, but it
escapes my knowledge:
1) create a static ARP entry, this will create an entry to
  the routing table i.e. arp -S IPADDR MACADDR
2) modify the mtu for that destination
  i.e. route change IPADDR -mtu MTU

HTH, Nikos