setting the other end's TCP segment size

perryh at perryh at
Sun Aug 3 21:25:00 UTC 2008

> > >> 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 08:00:20:00:a7:a6 UHLW     1  34 1500   xl0   1184

Now if I do

# route change -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.

More information about the freebsd-questions mailing list