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.