From owner-freebsd-current Wed Dec 16 12:45:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07854 for freebsd-current-outgoing; Wed, 16 Dec 1998 12:45:28 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07846 for ; Wed, 16 Dec 1998 12:45:23 -0800 (PST) (envelope-from paulz@trantor.stuyts.nl) Received: from stuyts by alushta.NL.net with UUCP id <10724-20085>; Wed, 16 Dec 1998 21:45:01 +0100 Received: from trantor.stuyts.nl (uucp@localhost) by terminus.stuyts.nl (8.9.1/8.9.1) with UUCP id UAA01962; Wed, 16 Dec 1998 20:59:47 +0100 (MET) (envelope-from paulz@trantor.stuyts.nl) Received: from trantor.stuyts.nl (localhost [127.0.0.1]) by trantor.stuyts.nl (8.9.1/8.8.5) with ESMTP id UAA31538; Wed, 16 Dec 1998 20:49:41 +0100 (MET) Message-Id: <199812161949.UAA31538@trantor.stuyts.nl> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith Cc: current@FreeBSD.ORG Subject: Re: Weird NFS error using Solaris 7 server In-reply-to: Your message of "Tue, 15 Dec 1998 17:58:45 PST." <199812160158.RAA00944@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Dec 1998 20:49:41 +0100 From: Paul van der Zwan Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I did some testing using the following test program: > > #include > > main() > > { > > int rv; > > rv=open("testfile1",O_CREAT|O_RDWR|O_EXCL,0666); > > if ( rv < 0 ) > > perror("testfile1"); > > rv=open("testfile2",O_CREAT|O_RDWR,0666); > > if ( rv < 0 ) > > perror("testfile2"); > > } > > > > This program results in a file called 'testfile1' being created on the server > > but having the creation of 'testfile2' fail with errno=79 ( which means > > EOVERFLOW 79 /* value too large to be stored in data type */ > > on Solaris ) > > > > If I do a snoop for the create requests sent I se the following request for > > testfile1 : > > RPC: ----- SUN RPC Header ----- > > RPC: > > RPC: Record Mark: last fragment, length = 156 > > RPC: Transaction id = 1478392196 > > RPC: Type = 0 (Call) > > RPC: RPC version = 2 > > RPC: Program = 100003 (NFS), version = 3, procedure = 8 > > RPC: Credentials: Flavor = 1 (Unix), len = 52 bytes > > RPC: Time = 0 > > RPC: Hostname = > > RPC: Uid = 544, Gid = 200 > > RPC: Groups = 200 0 5 14 68 69 70 1000 > > RPC: Verifier : Flavor = 0 (None), len = 0 bytes > > RPC: > > NFS: ----- Sun NFS ----- > > NFS: > > NFS: Proc = 8 (Create file) > > NFS: File handle = [008A] > > NFS: 0080000800000002000A000000000002694370EA000A000000000002694370EA > > NFS: File name = testfile1 > > NFS: Guard = 7F00000103000000 > > NFS: > > > > And the following for testfile2: > > RPC: ----- SUN RPC Header ----- > > RPC: > > RPC: Record Mark: last fragment, length = 192 > > RPC: Transaction id = 1478392200 > > RPC: Type = 0 (Call) > > RPC: RPC version = 2 > > RPC: Program = 100003 (NFS), version = 3, procedure = 8 > > RPC: Credentials: Flavor = 1 (Unix), len = 52 bytes > > RPC: Time = 0 > > RPC: Hostname = > > RPC: Uid = 544, Gid = 200 > > RPC: Groups = 200 0 5 14 68 69 70 1000 > > RPC: Verifier : Flavor = 0 (None), len = 0 bytes > > RPC: > > NFS: ----- Sun NFS ----- > > NFS: > > NFS: Proc = 8 (Create file) > > NFS: File handle = [008A] > > NFS: 0080000800000002000A000000000002694370EA000A000000000002694370EA > > NFS: File name = testfile2 > > NFS: Method = Unchecked > > NFS: Mode = 0644 > > NFS: Setuid = 0, Setgid = 0, Sticky = 0 > > NFS: Owner's permissions = rw- > > NFS: Group's permissions = r-- > > NFS: Other's permissions = r-- > > NFS: User ID = (not set) > > NFS: Group ID = (not set) > > NFS: Size = (not set) > > NFS: Access time = -1 (set to client time) > > NFS: Modification time = -1 (set to client time) > > NFS: > > NFS: > > > > So the open with the O_EXCL flag ( which succeeds ) shows a field decode by > > snoop as Guard and the failing request shows a lot of other fields. > > This looks like snoop is failing to usefully process the packet. Can > you feed the trace to Ethereal and see what it has to say about it? > The version of ethereal I have ( the one from the ports) cannot decode NFS packets. Maybe you have another version. I have checked rfc1813 for the NFS v3 spec and if the client is really setting the times to -1 it is not following the spec. It should fill a struct nfstime3 { uint32 seconds; uint32 nseconds; }; with the current time on the client and -1 is not a legal uint32. I started looking into the client code but haven't located the error ( yet). > > Hope someone can use this to find out what is wrong. > > ( If needed I can send the full snoop capture ) > > If you've got it in a format that can be used by other programs, please > do make it available somewhere. I have put the raw snoop capture on http://www.xs4all.nl/~paulz/snoop.log.gz (it is only 820 bytes) Paul -- Paul van der Zwan paulz @ trantor.stuyts.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message