Andrew Morton wrote:
On Wed, 15 Aug 2007 12:22:51 -0700 (PDT)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8891
Summary: in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4
requests
Product: Networking
Version: 2.5
KernelVersion: 2.6.22.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Most recent kernel where this bug did not occur: 2.6.20
Apparently a regression.
RPCBIND v4 requests are an experimental feature. They can be disabled
via a kernel build option (CONFIG_SUNRPC_BIND34). I think these are
left enabled in Fedora to find just the type of problem before v3 and v4
becomes the default.
Distribution: Fedora Core 6
Hardware Environment: x86_64
Software Environment: NFS
Problem Description: When locking a file, an invalid RPCBPROC_GETVERSADDR
procedure call is sent out
Steps to reproduce:
on the NFS server, run: tcpdump -xX -pni eth0 -s0 port 111 and src host
theNFSclient
on a client running 2.6.22.1, run: flock -x /nfsmount/somefile ls
tcpdump will show:
17:10:01.290655 IP 141.2.15.141.34572 > 141.2.1.1.sunrpc: P 0:168(168) ack 1
win 183 <nop,nop,timestamp 966695 115079499>
0x0000: 4500 00dc 53ad 4000 3f06 bcdc 8d02 0f8d [EMAIL PROTECTED]
0x0010: 8d02 0101 870c 006f cdcd 938d db00 c8a7
.......o........
0x0020: 8018 00b7 e59d 0000 0101 080a 000e c027 ...............'
0x0030: 06db f94b 8000 00a4 fd48 2a07 0000 0000 ...K.....H*.....
0x0040: 0000 0002 0001 86a0 0000 0004 0000 0009 ................
0x0050: 0000 0001 0000 0054 0000 03c6 0000 0007 .......T........
0x0060: 6572 6964 796b 6500 0000 0000 0000 0000 eridyke.........
0x0070: 0000 000e 0000 0000 0000 0001 0000 0002 ................
0x0080: 0000 0003 0000 0004 0000 0005 0000 0006 ................
0x0090: 0000 0007 0000 0007 0000 0009 0000 000a ................
0x00a0: 0000 000c 0000 0014 0000 001c 0000 0000 ................
0x00b0: 0000 0000 0001 86b5 0000 0004 0000 0003 ................
0x00c0: 7463 7000 0000 0009 3134 312e 322e 312e tcp.....141.2.1.
0x00d0: 3100 0000 0000 0004 7270 6362 1.......rpcb
Note the "141.2.1.1" in the output.
According to RFC 1833, you can read here the following fields:
RPCBPROC_GETVERSADDR version 4 procedure is being called
r_prog == 0x000186b5 == 100021 == nfs.lockd
r_vers == 4
r_netid == (length 3) "tcp"
r_addr == (length 9) "141.2.1.1"
r_owner == (length 4) "rpcb"
This r_addr member is supposed to contain an universal address. Although I have
no source for that, the RFC clearly says a service can listen to an address,
and RPCBPROC_GETVERSADDR is supposed to return an universal address too. From
this I can conclude that an universal address is supposed to contain the port
number, and other operating systems are using the format
a.b.c.d.PortHighByte.PortLowByte (like in FTP, but with . instead of ,). I
interpret the RFC 1833 so that the port number of the rpcbind, that is, 111, is
to be appended, so the correct value of r_addr would be "141.2.1.1.0.111". This
matches other implementations.
That RFC is unclear on exactly what a universal address should look
like. However speidel's interpretation is not unreasonable, and I'm
glad he was able to check this against other implementations that I
don't have. My unit testing against Solaris did not reveal this issue.
I'll look into the problem.
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard
