Re: rpc.lockd problems
Andrew P. Lentvorski wrote: Can you produce a packet trace for Kris? This would give him a known good trace so that he can point out the differences from his particular configuration, or, alternatively, he could file a bug report with the Linux folks. Ok, here is a but of output from tcpudmp, first is the locking of the file, later the unlocking of the file. (Beware, long lines ahead...) [This is when the locking begins-- I'm not sure if the RPC packets should be included...] 21:05:36.681339 dhcp157.in-10.sillywalks.org.49445 pluto.in-10.sillywalks.org.lockd: udp 196 (ttl 64, id 14737, len 224) 0x 4500 00e0 3991 4011 aa4c c0a8 0a9dE...9...@..L 0x0010 c0a8 0a42 c125 0fcd 00cc e277 3ddd 99f0...B.%.w=... 0x0020 0002 0001 86b5 0004 0x0030 0007 0001 0028 3dd7 f690...(=... 0x0040 0006 626f 656b 6a65 03e8boekje.. 0x0050 .. 21:05:36.684128 pluto.in-10.sillywalks.org.826 dhcp157.in-10.sillywalks.org.sunrpc: udp 84 (DF) (ttl 255, id 23949, len 112) 0x 4500 0070 5d8d 4000 ff11 87bf c0a8 0a42E..p].@B 0x0010 c0a8 0a9d 033a 006f 005c c339 b296 4aab.:.o.\.9..J. 0x0020 0002 0001 86a0 0002 0x0030 0003 0001 001c 3dd8 0492=... 0x0040 0005 706c 7574 6f00 pluto... 0x0050 21:05:36.685941 dhcp157.in-10.sillywalks.org.sunrpc pluto.in-10.sillywalks.org.826: [udp sum ok] udp 28 (ttl 64, id 14738, len 56) 0x 4500 0038 3992 4011 aaf3 c0a8 0a9dE..89...@... 0x0010 c0a8 0a42 006f 033a 0024 64b9 b296 4aab...B.o.:.$d...J. 0x0020 0001 0x0030 03d1 21:05:36.688612 pluto.in-10.sillywalks.org.825 dhcp157.in-10.sillywalks.org.977: udp 92 (DF) (ttl 255, id 23950, len 120) 0x 4500 0078 5d8e 4000 ff11 87b6 c0a8 0a42E..x].@B 0x0010 c0a8 0a9d 0339 03d1 0064 012b b296 4aac.9...d.+..J. 0x0020 0002 0001 86b5 0004 0x0030 000c 0001 001c 3dd8 0492=... 0x0040 0005 706c 7574 6f00 pluto... 0x0050 -- [The next part is when I close the file] -- 21:05:39.077292 dhcp157.in-10.sillywalks.org.49445 pluto.in-10.sillywalks.org.lockd: udp 180 (ttl 64, id 14742, len 208) 0x 4500 00d0 3996 4011 aa57 c0a8 0a9dE...9...@..W 0x0010 c0a8 0a42 c125 0fcd 00bc e1bd 3ddd 99f1...B.%..=... 0x0020 0002 0001 86b5 0004 0x0030 0009 0001 0028 3dd7 f693...(=... 0x0040 0006 626f 656b 6a65 03e8boekje.. 0x0050 .. 21:05:39.078515 pluto.in-10.sillywalks.org.825 dhcp157.in-10.sillywalks.org.977: udp 92 (DF) (ttl 255, id 12356, len 120) 0x 4500 0078 3044 4000 ff11 b500 c0a8 0a42E..x0D@B 0x0010 c0a8 0a9d 0339 03d1 0064 0026 b296 4aad.9...d...J. 0x0020 0002 0001 86b5 0004 0x0030 000e 0001 001c 3dd8 0494=... 0x0040 0005 706c 7574 6f00 pluto... 0x0050 - I hope this is enough info for you, if you need a real dump to look at yourself, just let me know, I'll put it online then. HTH, Martijn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
On Sun, Nov 17, 2002 at 09:31:40PM +0100, Martijn Pronk wrote: I hope this is enough info for you, if you need a real dump to look at yourself, just let me know, I'll put it online then. Thanks, but the binary dump would be more useful so I can read it into ethereal. ethereal does a really good job of decoding RPC requests, so I can see exactly what is going on and what is different from my linux case. Kris msg46829/pgp0.pgp Description: PGP signature
Re: rpc.lockd problems
Martijn Pronk wrote: My program is just anything that attempts to obtain a lock on a file on the NFS filesystem. vi does this when opening an existing file, as does mutt when opening a mailbox. Well, that sure simplifies the problem of running your program. ;) Thanks for the info, I will try that tonight after I get back home from the first day of the EuroBSDcon. OK, I tested it with a Solaris 8 NFS server with -current as a client, and locking does indeed work. (At least, vi didn't show the word UNLOCKED in the bottom line after I enabled rpc.lockd) However, I had some starting problems with rpc.lockd. Aparently it requires that rpc.statd also is running. Since I didn't had these things enabled in rc.conf, I started them manually. rpc.lockd quits silently without logging anything about what happened. The manualpage does mention that rpc.lockd typically runs in conjunction with rpc.statd As I don't see a direct requirement in this line, I didn't realize it was required. HTH, Martijn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
On Fri, 15 Nov 2002, Martijn Pronk wrote: However, I had some starting problems with rpc.lockd. Aparently it requires that rpc.statd also is running. Hmmm, it shouldn't fail if rpc.statd isn't enabled, but it should probably complain loudly. Make sure you file a FreeBSD bug report on that, and I'll go take a look why. statd is used to recover locks when the server dies or to release locks when the client dies. I don't actually know if it is required by the specification, but I don't think I've ever seen NFS used without it. Can you produce a packet trace for Kris? This would give him a known good trace so that he can point out the differences from his particular configuration, or, alternatively, he could file a bug report with the Linux folks. Thanks for taking the time to try the configuration, -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
On Wed, 13 Nov 2002, Kris Kennaway wrote: Yes, and I have no problems interoperating NFS under 4.x between these machines (or under 5.0 as long as I don't try and lock any files) - it's just 5.0's rpc.lockd. Can you help isolate the problem by trying this same operation from a Solaris NFS client? I'm actually happy to get bug reports about rpc.lockd as it means that someone is actually using my code. However, after having rewritten and debugged the FreeBSD rpc.lockd, I have no desire to debug the Linux one. ;) I believe that Linux client, at least, requires special patches to make its NFS properly compliant (it's not part of the main kernel tree). I don't track Linux enough to know if the server also requires something similar. See the talk from Connectathon 2002: http://www.connectathon.org/talks02/trond.pdf As well as the NFS patches at: http://www.fys.uio.no/~trondmy/ http://www.fys.uio.no/~trondmy/src/ -a -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
On Thu, Nov 14, 2002 at 01:47:43AM -0800, Andrew P. Lentvorski wrote: On Wed, 13 Nov 2002, Kris Kennaway wrote: Yes, and I have no problems interoperating NFS under 4.x between these machines (or under 5.0 as long as I don't try and lock any files) - it's just 5.0's rpc.lockd. Can you help isolate the problem by trying this same operation from a Solaris NFS client? I'm actually happy to get bug reports about rpc.lockd as it means that someone is actually using my code. However, after having rewritten and debugged the FreeBSD rpc.lockd, I have no desire to debug the Linux one. ;) Sorry, I have no access to a Solaris machine :( Kris msg46682/pgp0.pgp Description: PGP signature
rpc.lockd problems
A few months ago I posted about rpc.lockd interop problems I am having between my 5.0 NFS client and a Redhat 7.1 server. Both are running rpc.lockd, but when I send a lock request to the server it hangs forever blocked on the /var/run/lock socket. tcpdump shows that the lock RPC request is being sent, and answered by the server. I have the complete tcpdump trace if anyone is interested. 16:27:25.828109 citusc17.usc.edu.641493192 citusc.usc.edu.nfs: 140 access fh 0,1/117442560 003f 16:27:25.828897 citusc.usc.edu.nfs citusc17.usc.edu.641493192: reply ok 120 access c 0003 (DF) 16:27:25.829031 citusc17.usc.edu.641493193 citusc.usc.edu.nfs: 96 access fh Unknown/1 003f 16:27:25.829706 citusc.usc.edu.nfs citusc17.usc.edu.641493193: reply ok 120 access c 001f (DF) 16:27:25.829801 citusc17.usc.edu.641493194 citusc.usc.edu.nfs: 96 access fh Unknown/1 003f 16:27:25.830483 citusc.usc.edu.nfs citusc17.usc.edu.641493194: reply ok 120 access c 001f (DF) 16:27:28.257514 citusc17.usc.edu.641493195 citusc.usc.edu.nfs: 140 access fh 0,1/117442560 003f 16:27:28.258283 citusc.usc.edu.nfs citusc17.usc.edu.641493195: reply ok 120 access c 0003 (DF) 16:27:28.258427 citusc17.usc.edu.641493196 citusc.usc.edu.nfs: 96 access fh Unknown/1 003f 16:27:28.259107 citusc.usc.edu.nfs citusc17.usc.edu.641493196: reply ok 120 access c 001f (DF) 16:27:28.259317 citusc17.usc.edu.641493197 citusc.usc.edu.nfs: 104 lookup fh Unknown/1 incoming 16:27:28.260202 citusc.usc.edu.nfs citusc17.usc.edu.641493197: reply ok 232 lookup fh Unknown/1 (DF) 16:27:28.260344 citusc17.usc.edu.641493198 citusc.usc.edu.nfs: 96 access fh Unknown/1 003f 16:27:28.261022 citusc.usc.edu.nfs citusc17.usc.edu.641493198: reply ok 120 access c 001f (DF) 16:27:28.261119 citusc17.usc.edu.641493199 citusc.usc.edu.nfs: 100 access fh Unknown/1 003f 16:27:28.261808 citusc.usc.edu.nfs citusc17.usc.edu.641493199: reply ok 120 access c 000d (DF) 16:27:28.261918 citusc17.usc.edu.641493200 citusc.usc.edu.nfs: 100 access fh Unknown/1 003f 16:27:28.262608 citusc.usc.edu.nfs citusc17.usc.edu.641493200: reply ok 120 access c 000d (DF) 16:27:28.263888 citusc17.usc.edu.641493201 citusc.usc.edu.nfs: 140 setattr fh Unknown/1 16:27:28.264646 citusc.usc.edu.nfs citusc17.usc.edu.641493201: reply ok 120 setattr (DF) 16:27:28.285259 citusc17.usc.edu.641493202 citusc.usc.edu.nfs: 104 lookup fh Unknown/1 incoming 16:27:28.286179 citusc.usc.edu.nfs citusc17.usc.edu.641493202: reply ok 232 lookup fh Unknown/1 (DF) 16:27:28.287395 citusc17.usc.edu.55771 citusc.usc.edu.sunrpc: udp 56 16:27:28.288491 citusc.usc.edu.sunrpc citusc17.usc.edu.55771: udp 28 (DF) 16:27:28.289631 citusc17.usc.edu.55772 citusc.usc.edu.49437: udp 200 16:27:28.290549 citusc.usc.edu.49437 citusc17.usc.edu.55772: udp 28 (DF) Here is what rpc.lockd -d 10 shows: Nov 13 16:39:51 citusc17 rpc.lockd: process ID: 10865 Nov 13 16:39:51 citusc17 rpc.lockd: fh_len 24, fh \01\00\00\02\00\08\00\07\02\00\00\00\40\a0\0e\00\73\09\c6\11\2a\a0\0e\00 Nov 13 16:39:51 citusc17 rpc.lockd: start 0; len 0; pid 1; type 1; whence 0 Nov 13 16:39:51 citusc17 rpc.lockd: wait was not set Nov 13 16:39:51 citusc17 rpc.lockd: lock request: V4: read to 128.125.38.123 Nov 13 16:39:51 citusc17 rpc.lockd: Found CLIENT* in cache Nov 13 16:40:11 citusc17 rpc.lockd: process ID: 10865 Nov 13 16:40:11 citusc17 rpc.lockd: fh_len 24, fh \01\00\00\02\00\08\00\07\02\00\00\00\40\a0\0e\00\73\09\c6\11\2a\a0\0e\00 Nov 13 16:40:11 citusc17 rpc.lockd: start 0; len 0; pid 1; type 1; whence 0 Nov 13 16:40:11 citusc17 rpc.lockd: wait was not set Nov 13 16:40:11 citusc17 rpc.lockd: lock request: V4: read to 128.125.38.123 Nov 13 16:40:11 citusc17 rpc.lockd: Found CLIENT* in cache Nov 13 16:40:31 citusc17 rpc.lockd: process ID: 10865 Nov 13 16:40:31 citusc17 rpc.lockd: fh_len 24, fh \01\00\00\02\00\08\00\07\02\00\00\00\40\a0\0e\00\73\09\c6\11\2a\a0\0e\00 Nov 13 16:40:31 citusc17 rpc.lockd: start 0; len 0; pid 1; type 1; whence 0 Nov 13 16:40:31 citusc17 rpc.lockd: wait was not set Nov 13 16:40:31 citusc17 rpc.lockd: lock request: V4: read to 128.125.38.123 Nov 13 16:40:31 citusc17 rpc.lockd: Found CLIENT* in cache (this repeats every 20 seconds) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
* Kris Kennaway [EMAIL PROTECTED] [021113 16:41] wrote: A few months ago I posted about rpc.lockd interop problems I am having between my 5.0 NFS client and a Redhat 7.1 server. Both are running rpc.lockd, but when I send a lock request to the server it hangs forever blocked on the /var/run/lock socket. tcpdump shows that the lock RPC request is being sent, and answered by the server. I have the complete tcpdump trace if anyone is interested. Ah finally! Some useful debug info! It looks like the remote server is not running lockd, or posibly just dropping the lock requests on the floor. Can you get some information about the remote lockd? 16:27:28.285259 citusc17.usc.edu.641493202 citusc.usc.edu.nfs: 104 lookup fh Unknown/1 incoming 16:27:28.286179 citusc.usc.edu.nfs citusc17.usc.edu.641493202: reply ok 232 lookup fh Unknown/1 (DF) 16:27:28.287395 citusc17.usc.edu.55771 citusc.usc.edu.sunrpc: udp 56 16:27:28.288491 citusc.usc.edu.sunrpc citusc17.usc.edu.55771: udp 28 (DF) 16:27:28.289631 citusc17.usc.edu.55772 citusc.usc.edu.49437: udp 200 16:27:28.290549 citusc.usc.edu.49437 citusc17.usc.edu.55772: udp 28 (DF) Ok, here's where the lock request is done... Here is what rpc.lockd -d 10 shows: Nov 13 16:39:51 citusc17 rpc.lockd: process ID: 10865 Nov 13 16:39:51 citusc17 rpc.lockd: fh_len 24, fh \01\00\00\02\00\08\00\07\02\00\00\00\40\a0\0e\00\73\09\c6\11\2a\a0\0e\00 Nov 13 16:39:51 citusc17 rpc.lockd: start 0; len 0; pid 1; type 1; whence 0 Nov 13 16:39:51 citusc17 rpc.lockd: wait was not set Nov 13 16:39:51 citusc17 rpc.lockd: lock request: V4: read to 128.125.38.123 Nov 13 16:39:51 citusc17 rpc.lockd: Found CLIENT* in cache Nov 13 16:40:11 citusc17 rpc.lockd: process ID: 10865 Nov 13 16:40:11 citusc17 rpc.lockd: fh_len 24, fh \01\00\00\02\00\08\00\07\02\00\00\00\40\a0\0e\00\73\09\c6\11\2a\a0\0e\00 Nov 13 16:40:11 citusc17 rpc.lockd: start 0; len 0; pid 1; type 1; whence 0 Nov 13 16:40:11 citusc17 rpc.lockd: wait was not set Nov 13 16:40:11 citusc17 rpc.lockd: lock request: V4: read to 128.125.38.123 Nov 13 16:40:11 citusc17 rpc.lockd: Found CLIENT* in cache Nov 13 16:40:31 citusc17 rpc.lockd: process ID: 10865 Nov 13 16:40:31 citusc17 rpc.lockd: fh_len 24, fh \01\00\00\02\00\08\00\07\02\00\00\00\40\a0\0e\00\73\09\c6\11\2a\a0\0e\00 Nov 13 16:40:31 citusc17 rpc.lockd: start 0; len 0; pid 1; type 1; whence 0 Nov 13 16:40:31 citusc17 rpc.lockd: wait was not set Nov 13 16:40:31 citusc17 rpc.lockd: lock request: V4: read to 128.125.38.123 Nov 13 16:40:31 citusc17 rpc.lockd: Found CLIENT* in cache (this repeats every 20 seconds) Neither the tcpdump nor the lockd debug output show any response from the server... can you look into this? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
On Wed, Nov 13, 2002 at 06:13:21PM -0800, Terry Lambert wrote: Kris Kennaway wrote: A few months ago I posted about rpc.lockd interop problems I am having between my 5.0 NFS client and a Redhat 7.1 server. Both are running rpc.lockd, but when I send a lock request to the server it hangs forever blocked on the /var/run/lock socket. tcpdump shows that the lock RPC request is being sent, and answered by the server. I have the complete tcpdump trace if anyone is interested. This might be a long standing problem that FreeBSD has serving UDP NFS client requests. You need to look at the packets. Is the IP on the response the same as the one on the request? Yes, and I have no problems interoperating NFS under 4.x between these machines (or under 5.0 as long as I don't try and lock any files) - it's just 5.0's rpc.lockd. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
