http://bugzilla.novell.com/show_bug.cgi?id=495130 Leon Wang 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 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 User sjayaraman@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=495130#c1 Suresh Jayaraman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |hpj@urpla.net --- Comment #1 from Suresh Jayaraman 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 http://bugzilla.novell.com/show_bug.cgi?id=495130#c4 --- Comment #4 from Suresh Jayaraman 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#c6 --- Comment #6 from Neil Brown 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.