Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.hawaii.edu!ames!enews.sgi.com!sgigate.sgi.com!news.msfc.nasa.gov!newsfeed.internetmci.com!in2.uu.net!news.BSDI.COM!usenet
From: Tony Sanders <sanders@earth.com>
Newsgroups: comp.unix.bsd.bsdi.misc
Subject: Re: Setting MTU size in 2.1?
Date: Wed, 24 Apr 1996 01:17:34 -0500
Organization: Berkeley Software Design, Inc.
Lines: 43
Message-ID: <317DC77E.41C67EA6@earth.com>
References: <4krvmi$t50@news.enterprise.net> <4l134a$4i3@jade.emeraldis.com>
NNTP-Posting-Host: austin.bsdi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; BSD/OS 2.0 i386)
David G. Cannon wrote:
> In article <4krvmi$t50@news.enterprise.net>, apc@enterprise.net (Adrian
> Cooper) wrote:
> > Any words of wisdom regarding the MTU size or the local speed peculiarity
> > would be most welcome.
...
> I'm not an expert, but as far as I know, BSDI will negotiate the MTU size
> depending on the clients settings. For example, it is necessary to set Trumpet
> Winsock to use an MTU size of 512 in order to work properly. BSDI will
> accommodate this by setting it's MTU to 512. There is no changes necessary on
> the BSDI box.
>
> *David*
The Windows for Workgroups Ethernet driver and the Windows 3.1 PPP
driver are known to fail in this way (probably others but I know
about those two for sure). The problem is that during TCP option
negotiation they will claim to support full size TCP segments (mss
1500) but then will ignore all packets over 1024 bytes.
BSD/OS V1.1 worked with those systems because we previously only
negotiated segments upto 1024 bytes. Starting with BSD/OS V2.0 we
support upto 1460 on ethernet segments so people starting see the
problem. If you see small packets (packets less than 1024 bytes)
getting through but larger transfers failing then you have the
problem (e.g., telnet's will often work but ftp and web transfers
will fail).
Non-local routes have a default smaller than 1024 so you'll also
notice that you can talk to far away Windows systems but not
local Windows systems.
The best solution would be to get fixed drivers for Windows
but, as a workaround, you can limit the MTU on a route-by-route
basis in BSD/OS using:
route change <dest> -mtu 1024
route change default -mtu 512
route change -net 10.1.1 -mtu 1024
[you can view your current routes with ``netstat -rn'' and you
can examine the route selection for a given IP address using
``route get IP.ADDR''].
Hope that helps.