Re: setting the other end's TCP segment size

On Monday 04 August 2008 00:16:54 perryh@xxxxxxxxxxxxxx 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
_______________________________________________
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: Change MTU for gprs connection
    ... I'm able to change the MTU for the ethernet connection because therefore I ... that I don't have such an entry for the gprs connection. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: setting the other ends TCP segment size
    ... peer to use a transmit segment size of, say, 640 bytes -- ... packet size directly. ... 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
    ... > 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: Change MTU for gprs connection
    ... me where to add the entry and how it looks like. ... with wavecom Q2501 gprs module. ... But I have same connection problems so ... Have you entered "MTU" in the Search pane for the Platform Builder ...
    (microsoft.public.windowsce.platbuilder)
  • [PATCH] AF_RXRPC: Sort out MTU handling
    ... Sort out the MTU determination and handling in AF_RXRPC: ... parse the additional information supplied by the peer at ... the end of the ACK packet to determine the MTU sizes ... Send ACKs rather than ACKALLs as the former carry the additional info, ...
    (Linux-Kernel)