Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jul 1999 16:58:19 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc:        crossd@cs.rpi.edu, current@FreeBSD.ORG
Subject:   Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm
Message-ID:  <199907282358.QAA64519@apollo.backplane.com>
References:   <199907282340.TAA15454@skynet.ctr.columbia.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
:>    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 
					<dillon@backplane.com>

:-- 
:=============================================================================
:-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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907282358.QAA64519>