From owner-freebsd-current Wed Jul 28 16:58:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4EBF11551D for ; Wed, 28 Jul 1999 16:58:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA64519; Wed, 28 Jul 1999 16:58:19 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 16:58:19 -0700 (PDT) From: Matthew Dillon Message-Id: <199907282358.QAA64519@apollo.backplane.com> To: Bill Paul Cc: crossd@cs.rpi.edu, current@FreeBSD.ORG Subject: Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm References: <199907282340.TAA15454@skynet.ctr.columbia.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Ah ha! Yes, 32K packets will certainly screw up NFS under FreeBSD. : :Uh.... could you elaborate a little? No, strike that: could you elaborate :a *lot*. A whole lot. Sure. There is a constant called NFS_MAXDATA defined in ..mmm.. nfs/nfsproto.h. Set to 32768 for TCP connections, 16384 for UDP connections. The code is a mess though, so usually just the higher limit is used. The fsinfo rpc returns this maximum to the client. The client is supposed to limit NFS packets to the specified size. :> We need to fix that panic to have it simply drop the packet, I guess. : :No, we need to fix the code so it handles 32K "packets" (datagrams) :correctly. : :-Bill But there is a bug somewhere. Nobody has been able to find it yet. There are cases where the server will attempt to return a packet that is larger then 32K. It's probably due to some NFS header records that aren't being accounted for. But where, I don't know. I'm guessing in the read or write code somewhere. The server panics if an rpc reply winds up being larger then NFS_MAXDATA. That is, when a packet generated by the server in response to a client request winds up being larger then NFS_MAXDATA. There could also be some confusion in the spec. I'm not sure whether NFS_MAXDATA refers to the maximum NFS message size inclusive of NFS headers, or just the data portion of the NFS message. It might help to get a backtrace if you have a kernel set to drop into DDB on a panic. This would be the 'trace' command from the DDB prompt. I could try to locate where the limit is being smashed. -Matt Matthew Dillon :-- :============================================================================= :-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu :Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research :Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City :============================================================================= : "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" :============================================================================= : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message