From owner-freebsd-questions@FreeBSD.ORG Mon Aug 4 13:19:49 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33931065676 for ; Mon, 4 Aug 2008 13:19:49 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8BE8FC08 for ; Mon, 4 Aug 2008 13:19:49 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id 84939142087; Mon, 4 Aug 2008 16:19:48 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.5 Received: from iris.teledomenet.local (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id 7D67C14208E; Mon, 4 Aug 2008 16:19:12 +0300 (EEST) From: Nikos Vassiliadis To: perryh@pluto.rain.com Date: Mon, 4 Aug 2008 16:20:36 +0300 User-Agent: KMail/1.9.7 References: <488fe865.x7NyNic2A5pcZPCL%perryh@pluto.rain.com> <200807311027.37878.nvass@teledomenet.gr> <48962046.334w0KWDk7nStfQ/%perryh@pluto.rain.com> In-Reply-To: <48962046.334w0KWDk7nStfQ/%perryh@pluto.rain.com> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808041620.37610.nvass@teledomenet.gr> Cc: keramida@ceid.upatras.gr, freebsd-questions@freebsd.org, derek@computinginnovations.com Subject: Re: setting the other end's TCP segment size X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 13:19:49 -0000 On Monday 04 August 2008 00:16:54 perryh@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