[Bug 495130] New: rpmbind is incompatible with earlier versions of udev's nfsmount
http://bugzilla.novell.com/show_bug.cgi?id=495130 Summary: rpmbind is incompatible with earlier versions of udev's nfsmount Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: i686 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: hpj@urpla.net QAContact: qa@suse.de Found By: Beta-Customer Created an attachment (id=285871) --> (http://bugzilla.novell.com/attachment.cgi?id=285871) tcpdump I suffered from a problem, where my diskless environment didn't work anymore after upgrading the server from openSUSE 11.0 to openSUSE 11.1. The (legacy) diskless environment gets set up with an customized initrd via pxelinux. It is SuSE 9.3 based. The initrd uses klibc's nfsmount from udev-053, and I've tried both protocols: udp and tcp. It's not an iptables issue, since I can mount these directories from other (fully booted) systems just fine. Using the debug version of klibc's nfsmount prints these messages: short read: 0 < 28 Port for 100003/3[udp]: 0 short read: 0 < 28 Port for 100005/3[udp]: 0 NFS params: server = xxx.xx.xx.xx, path = "/roroot", version = 3, proto = udp, mount_port = 627, nfs_port = 2049, flags = 00010282, rsize = 0, wsize = 0, timeo = 7, retrans = 3, acreg (min,max) = (3,60), acdir (min,max) = (30,60), soft = 0, intr = 1, posix = 0, nocto = 0, noac = 0 tcpdumping the communication shows, that for whatever reason, the client sends the mount request from source port 798 to destination port 627, but the server doesn't listen on 627: # rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 41656 mountd 100005 1 tcp 49063 mountd 100005 2 udp 41656 mountd 100005 2 tcp 49063 mountd 100005 3 udp 41656 mountd 100005 3 tcp 49063 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 udp 33144 nlockmgr 100021 3 udp 33144 nlockmgr 100021 4 udp 33144 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 tcp 57268 nlockmgr 100021 3 tcp 57268 nlockmgr 100021 4 tcp 57268 nlockmgr 100024 1 udp 39508 status 100024 1 tcp 45430 status I've attached the relevant tcpdump section. After replacing rpcbind-0.1.6+git20080930-5.2 with portmap-6.0+git20070716-31.37, all is well again. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 Leon Wang <llwang@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |llwang@novell.com AssignedTo|bnc-team-screening@forge.pr |kernel-maintainers@forge.pr |ovo.novell.com |ovo.novell.com -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 Jeff Mahoney <jeffm@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|rpmbind is incompatible |rpcbind is incompatible |with earlier versions of |with earlier versions of |udev's nfsmount |udev's nfsmount -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 Jeff Mahoney <jeffm@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffm@novell.com AssignedTo|kernel-maintainers@forge.pr |sjayaraman@novell.com |ovo.novell.com | -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 Suresh Jayaraman <sjayaraman@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 User sjayaraman@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=495130#c1 Suresh Jayaraman <sjayaraman@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |hpj@urpla.net --- Comment #1 from Suresh Jayaraman <sjayaraman@novell.com> 2009-05-12 07:38:50 MDT --- Thanks for the bug report. Looking at the traces, there were no portmap GETPORT calls. There was only a DUMP call but the client was not trying to use the mountd port returned as part of DUMP reply from the server. The client sends mount request but to the wrong port - 627 is the not server's mountd port. Does using "mountport=<port>" option help? (mount port can be obtained from rpcinfo -p (mountd vers 3) AFAICT, Rpcbind is backward compatible but not sure whether a it works fine with a kernel that is as old as 2.6.11 (present in 9.3). It is not clear why client is not sending GETPORT calls but still using a port where mountd is not listening. Similarly it is not clear why the problem goes away while replacing rpcbind with portmap. Enabling rpc debugging might give some clues. Can you enable rpc debugging on both client and server by doing: echo 65535 > /proc/sys/sunrpc/rpc_debug and attach the dmesg/syslog output? Also, if possible see whether the problem is reproducible with client > 9.3. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 User nfbrown@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=495130#c3 Neil Brown <nfbrown@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nfbrown@novell.com --- Comment #3 from Neil Brown <nfbrown@novell.com> 2009-06-11 00:36:11 MDT --- nfsmount from klibc uses port 627 by default if it cannot get an answer from portmap. The tcpdump trace shows: - a 'DUMP' request and reply - I don't know where this comes from - a GET_PORT request (packet 19) for NFSv3 with no reply - a 60 second pause after which rpcbind closes the connection - a GET_PORT request (packet 28) for MOUNT v3 with no reply - a 60 second pause after which rpcbind closed the connection - a MOUNT request on port 627 - the default. So rpcbind simply isn't replying to either GET_PORT requests. The only thing that looks at all odd about the GET_PORT requests is that the credentials and verifier are all '0'. This should be perfectly legal, but maybe it is confusing rpcbind. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 http://bugzilla.novell.com/show_bug.cgi?id=495130#c4 --- Comment #4 from Suresh Jayaraman <sjayaraman@novell.com> 2009-12-16 13:10:57 UTC --- Back to this after a while, I still don't see any GETPORT procedure calls at all in the packet capture (tried wireshark, tshark and tcpdump). Perhaps am I missing something? Neil: Which one did you use to interpret packets? Hans: Did the mountproto option help? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 http://bugzilla.novell.com/show_bug.cgi?id=495130#c5 --- Comment #5 from Hans-Peter Jansen <hpj@urpla.net> 2009-12-16 13:42:28 UTC --- Suresh, thanks for your care. It will take some time to recreate the setup, as some other projects occupy my precious office space atm. But creating a new diskless setup is scheduled early next year, I will have to do that soon. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 http://bugzilla.novell.com/show_bug.cgi?id=495130#c6 --- Comment #6 from Neil Brown <nfbrown@novell.com> 2009-12-17 21:30:58 UTC --- Hi Suresh ... you are being too dependent on your tools :-) I use wireshark to look at the trace, and it doesn't decode packet 19 as a portmap request, but it is one none-the-less. If you select "TCP segment data" it will highlight some bytes in the bottom pane. These are: 80 00 00 3c RPC stream packet header for a 60 bytes packets b2 79 a6 5d xid for the request 00 00 00 00 0 == "Request" (1 would mean "reply") 00 00 00 02 RPC protocol version number, always 2 00 01 86 a0 == 100000 maps to "portmap" in /etc/rpc 00 00 00 02 version 2 of the portmap protocol 00 00 00 03 procedure 3 is PMAPPROC_GETPORT 00 00 00 00 AUTH_NULL I think - more zeros for the content of AUTH_NULL and the verifier 00 01 86 a3 100003 - the program number for "nfs" 00 00 00 03 requesting version 3 of NFS 00 00 00 11 17 is IPPROTO_UDP 00 00 00 00 0 for the port number in the request. I wonder why wireshark cannot decode that ... it decodes packet 9 quite successfully, and it is very similar... Wait - I know. The RPC header says there should be 60 bytes following, but there are only 56 bytes following, so it isn't a complete packet. And looking in klibc-0.196 in the udev-053-15.src.rpm from 9.3, the code does the wrong thing. in nfsmount/sunrpc.c, in rpc_header() The 'rpc->call_len' includes the size of the RPC header, but the hdr.frag_hdr must not. So a " - 4" is missing. This was fixed in kilbc 1.5.1 http://git.kernel.org/?p=libs/klibc/klibc.git;a=commitdiff;h=0098b1279e9c135... So while it seems that moving from portmap to rpcbind has caused a regression, this really is a bug in klibc and I don't think it is justified to hack rpcbind to be bug-for-bug compatible. I assume suse will continue to package portmap, and people who need the old bugs can still install it. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=495130 http://bugzilla.novell.com/show_bug.cgi?id=495130#c7 Suresh Jayaraman <sjayaraman@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|hpj@urpla.net | Resolution| |WONTFIX --- Comment #7 from Suresh Jayaraman <sjayaraman@novell.com> 2009-12-18 12:39:21 UTC --- Great, Thanks Neil! The problem is due to a bug in version of klibc that is being used in SUSE Linux Professional 9.3 (unsupported) and there is still portmap available in openSUSE 11.x version that can be used to make NFS work with buggy 9.3 clients, I'll fix this as WONT FIX. Thanks! -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com