Re: setting the other end's TCP segment size

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.
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Intermittently Unable To Send Email
    ... > The last entry into the SMTP Log is 354 go ahead. ... Unfortunately that log entry may also mean that it has already sent ... The only way to know for sure is to take a packet ... In that case perhaps you have an MTU size issue to deal with. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: Intermittently Unable To Send Email
    ... Spot on Robert! ... everything seemed OK until the last entry ... The problem was cured by adding an MTU to the ... The only way to know for sure is to take a packet ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: setting the other ends TCP segment size
    ... peer to use a transmit segment size of, say, 640 bytes -- ... That would be better than setting the local mtu -- which has been ... -- the entry still expires and loses the mtu specification. ...
    (freebsd-questions)
  • Re: Intermittently Unable To Send Email
    ... > Spot on Robert! ... > was no full stop in the log file entry. ... The only way to know for sure is to take a packet ... >> In that case perhaps you have an MTU size issue to deal with. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: MSS on router, why?
    ... The proper way to describe the ICMP packet which is supposed to be ... returned by a router which cannot forward the IP packet which is too ... Because ICMP was defined before Path MTU Discovery (1981 and 1990 ... fragmentation and try to use path MTU discovery, ...
    (comp.dcom.sys.cisco)