*BSD News Article 14069


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!rutgers!igor.rutgers.edu!geneva.rutgers.edu!hedrick
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.os.386bsd.questions
Subject: Re: NFS PROBLEMS AFTER PATCH 0.2.2
Message-ID: <Apr.5.21.43.08.1993.3135@geneva.rutgers.edu>
Date: 6 Apr 93 01:43:09 GMT
References: <733572001snz@feline.demon.co.uk> <C4ttG9.2qB@news.cso.uiuc.edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 33

rkb55989@uxa.cso.uiuc.edu (Rafal) writes:

>	I am running a 0.2.1 system, and am seeing similar problems. Just
>	for reference, I am running over SLIP, with my MTU [on the BSD box]
>	set at the standard 296.  The terminal server I connect to claims it
>	is using an MTU of 1536, but all works with the standard BSD MTU,
>	except NFS [well, it works somewhat].

I'm basing these comments on general BSD knowledge, not specific
knowledge of the 386bsd code.  TCP should be no problem.  The kernel
will send a TCP MSS option when opening the connection.  The MSS it
chooses will be based on the MTU.  Assuming that the other end
implements MSS correctly (I've seen some oddities with Solaris), no
TCP packet will exceed 296 bytes, and you'll be fine.  There is no
equivalent mechanism for UDP.  Typically NFS is implemented on top of
UDP.  Assuming that the other system is on an Ethernet, it will
fragment the NFS transmission into 1500-byte UDP packets.  Since the
terminal server has a full-size MTU, it will pass those packets
unchanged.  Unfortunately, the BSD SLIP implemenetations that I've
seen will throw away any incoming packets larger than its MTU.  So
you lose.

If this occurs with 386bsd, I can see several possible solutions:
  - increase the MTU to 1500 bytes (or whatever number you need
	to account for overhead).
  - decrease the terminal server MTU to 296 (or whatever number
	is needed to account for overhead).  At least with Cisco
	terminal servers, that will cause the terminal server
	to fragment the packets to 296 bytes.  BSD should 
	then be able to handle them.
  - specify rsize=296 (minus some number of overhead bytes, I
	suspect).  But I have a feeling this isn't going to be
	practical.