Date: Thu, 13 Nov 2008 11:02:15 +0000 From: Doug Rabson <dfr@rabson.org> To: Navdeep Parhar <nparhar@gmail.com> Cc: dfr@freebsd.org, freebsd-current@freebsd.org Subject: Re: problems with nfsd (due to RPCSEC_GSS changes?) Message-ID: <3BFE7716-48E7-4AE9-BE82-611FBA57C837@rabson.org> In-Reply-To: <d04e16b70811121136x4e7be24ev756e5e1d0d133e81@mail.gmail.com> References: <d04e16b70811111730w1bb7766ei4a628f2d8ddd9078@mail.gmail.com> <440834F1-1CA0-424F-915F-3B3CD773F83B@rabson.org> <d04e16b70811121136x4e7be24ev756e5e1d0d133e81@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Nov 2008, at 19:36, Navdeep Parhar wrote: > On Wed, Nov 12, 2008 at 1:20 AM, Doug Rabson <dfr@rabson.org> wrote: >> >> On 12 Nov 2008, at 01:30, Navdeep Parhar wrote: >> >>> I had a FreeBSD NFS server running a month+ old current (from Oct >>> 2 or >>> so). I upgraded to a current current (Nov 11) and nfsd stopped >>> working. >>> I was able to mount the exported filesystem but anything else would >>> yield an "Input/output error." nfsstat -s showed "Server Ret-Failed" >>> going up everytime I tried a 'cd', 'ls', etc. from the client. (I >>> tried >>> both FreeBSD and Solaris clients). >>> >>> Ultimately, I had to add NFS_LEGACYRPC in order to get a working >>> nfsd. >>> Looks like there may be a problem with the new code that was added >>> as >>> part of RPCSEC_GSS support. Note that I did not enable KGSSAPI in >>> my >>> kernel as I have no need for it. >>> >>> Are there any knows issues with the new code? Feel free to ask if >>> you >>> need any more information about my setup. >> >> I don't know of anything specific. If I could see a packet trace >> including >> both the mount request and at least one failed access attempt, it >> would help >> to understand what is happening here. >> > > I saw a handful of commits from you last night so I updated + > rebuilt the > server's kernel to include them. These traces are with today's code > (Nov12 > 11AM Pacific) on the server and yesterday's code on the client. > > The server is .2 and the client is .1, the trace is using tcpdump -s > 256 -vvn on the server. > > # mount /usr/obj (and then wait a couple of seconds. The mount > succeeds) Could you try this again with 'tcpdump -w foo.pcap ...' and then send me the resulting file - its very hard to see what is really happening from a simple tcpdump output.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BFE7716-48E7-4AE9-BE82-611FBA57C837>