Bug 140016

Summary: mount utility ignores "-o udp" option
Product: [Fedora] Fedora Reporter: Alexey Budankov <alexey.budankov>
Component: util-linuxAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: astrand, dmateo, doug, notting, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-24 13:26:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A patch that makes both mount and umount adhere to the current IP protocol.
none
.spec file for applying suggested above patch and building rpm none

Description Alexey Budankov 2004-11-19 10:56:31 UTC
Description of problem:

I tried to mount some of my NFS shares loacated behind a firewall 
using "-o udp" option: 
user@linux]$ mount -o udp server:/directory/folder  /mnt/nfs/folder
udp ports were specially opened on the firewall but tcp ones weren't.
Mount operation hanged for ~ 5 minutes. The mount connection was 
displayed in "netstat -a" as went over tcp protocol.
Interesting fact that the same mounting command worked just fine on 
SuSE 9.1 and SLES 9.0 distros - they have util-linux version 2.12-72 
and , as well as FC2, kernel 2.6. However if I didn't specify 
explicitly "-o udp" behaviour on SUSE distros was the same. When I 
replaced /bin/mount,/bin/umount binaries on FC2 with the same ones 
from  SUSE9.1 distro, the issue went away. Also the problem presents 
in util-linux from FC3 and is reproduced on EM64T architecture.

Version-Release number of selected component (if applicable):
util-linux-2.12-18 - FC2
util-linux-2.12a-16 - FC3

How reproducible:
always

Steps to Reproduce:
1. Install FC2
2. Try mount any NFS share over udp - 
[user@linux]$ mount -o udp server:/directory/folder  /mnt/nfs/folder
3.Use netstat for example:
[user@linux]$ netstat -a
There will be your nfs connection but established over tcp protocol.
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         
State       PID/Program name   
...
it is here ===> tcp        0      1 FC2.intel:996 server.int:4046 
SYN_SENT    2087/mount          
tcp        0      0 *:ssh                   *:*                     
LISTEN      1733/sshd           
tcp        0      0 localhos:x11-ssh-offset *:*                     
LISTEN      1988/0              
tcp        0      0 localhost:6011          *:*                     
LISTEN      2029/1              
tcp        0      0 localhost:6012          *:*                     
LISTEN      2088/2              
tcp        0      0 nntvtune20.inn.inte:ssh abudanko-linux.in:33368 
ESTABLISHED 1988/0              
tcp        0      0 nntvtune20.inn.inte:ssh abudanko-linux.in:33369 
ESTABLISHED 2029/1              
tcp        0    144 nntvtune20.inn.inte:ssh abudanko-linux.in:33372 
ESTABLISHED 2088/2              
udp        0      0 *:32768                 
*:*                                 1635/rpc.statd      
udp        0      0 *:963                   
*:*                                 1635/rpc.statd      
udp        0      0 *:sunrpc                
*:*                                 1615/portmap        
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program 
name    Path
unix  4      [ ]         DGRAM                    2673   
1582/syslogd        /dev/log
unix  2      [ ACC ]     STREAM     LISTENING     2994   
1759/xfs            /tmp/.font-unix/fs7100
unix  2      [ ]         DGRAM                    2742   
1635/rpc.statd      
unix  2      [ ]         DGRAM                    2682   
1586/klogd        
Actual results:


Expected results:


Additional info:

Comment 1 Steve Dickson 2004-11-20 00:59:44 UTC
I am of the opition that is this more of a firewall bug
than an NFS problem becuase neither FC2 or FC3 mount command
ignore the udp option. 

Comment 2 Alexey Budankov 2004-11-22 07:16:13 UTC
OK, but the same utilities work perfect on SUSE. Anyway I can't 
exactly know what the problem is in, but this only happens on FC2/3 
for me.

Comment 3 Steve Dickson 2004-11-22 16:25:18 UTC
Try 'service iptables stop' and then the mount....

Comment 4 Alexey Budankov 2004-11-23 07:31:43 UTC
Hi,
Of course, I disabled all local firewall services and iptables sevice 
first time, before mounting, but it did'not help.

Thanks,
Alexey

Comment 5 Steve Dickson 2004-11-23 21:07:20 UTC
I didn't didn't mean to in insultive... :) I just wanted to cover the
obvious.....

Now what troubles me with the  
"it is here ===> tcp 0 1 FC2.intel:996 server.int:4046 "
is 4046 is the not the port that NFS listens on,  2049 is the port
so I would have expected some like:  "FC2.intel:996 server.int:nfs" or
"FC2.intel:996 server.int:2049" if TCP was really being used.... 

Comment 6 Alexey Budankov 2004-11-24 07:25:52 UTC
Hi Steve,
First, you are right - 4046 is not the apropriate port for nfs - the 
2049 port is, but the question is why mount tried to operate over tcp 
whereas I explicitly made it to connect over udp.
Second, "FC2.intel:996 server.int:nfs" from your previous message 
indeed appears but only after about 5 minutes and nfs connection is 
really established then.

My question is why it hangs so long, while other utilities operate 
much more faster (I mean other distros).

Thanks,
Alexey


Comment 7 Steve Dickson 2004-11-29 15:05:50 UTC
Yes this is a problem... looking at a network trace it seems
rpc.mountd creates a TCP connection to the server even when
the "-o udp" mount is used. 

Comment 8 Steve Dickson 2004-11-29 20:24:24 UTC
Created attachment 107572 [details]
A patch that makes both mount and umount adhere to the current IP protocol.

To make NFS mount and umount firewall friendlier, the communication
between rpc.mound and the nfs server need to used the same IP protocol
that is given on the command line.

Comment 9 Alexey Budankov 2004-11-30 05:10:18 UTC
Created attachment 107604 [details]
.spec file for applying suggested above patch and building rpm

replace original util-linux.spec with the new one

Comment 10 Alexey Budankov 2004-11-30 05:16:34 UTC
Hi Steve,
I tried your fix and it indeed worked perfect for me, it is good 
job :), thanks! I also attached new .spec file for building fixed 
binaries. 

Thanks,
Alexey


Comment 11 Steve Dickson 2004-11-30 13:48:07 UTC
Fixed in util-linux-2.12-19.i386.rpm for FC2
Fixed in util-linux-2.12a-17.i386.rpm for FC3



Comment 12 Steve Dickson 2004-12-11 01:20:39 UTC
*** Bug 128100 has been marked as a duplicate of this bug. ***

Comment 13 Peter Åstrand 2005-02-25 13:44:17 UTC
The fixed util-linux package is *still* not available in
updates-stable. Why?

Comment 14 Steve Dickson 2005-03-03 06:45:14 UTC
It should be available now... 

Comment 17 Peter Åstrand 2005-03-11 08:30:52 UTC
>It should be available now... 

Well, it's not in
ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/2/i386/
yet...


Comment 18 Peter Åstrand 2005-03-14 12:46:37 UTC
It's not in
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/i386/
either. 

Comment 19 Peter Åstrand 2005-03-24 14:01:36 UTC
"CURRENTRELEASE" means: "The problem described has already been fixed and can be
obtained in the latest version of our product."

The latest version of Fedora is FC3, and the bug is still present in FC3. No
fixed util-linux package has been released as stable for FC3, at least not in
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/. 

So, closing this bug with CURRENTRELEASE seems wrong to me. 

Comment 20 Steve Dickson 2005-03-28 13:32:56 UTC
I'm not sure why these updates are not being pushed out but
I put the latest rpm and srpm in  http://people.redhat.com/steved/bz140016/

Comment 21 Bill Nottingham 2005-03-28 19:59:47 UTC
No one requested that these be pushed from final to testing... is that a request?

Comment 22 Steve Dickson 2005-03-30 19:09:36 UTC
I guess that was my fault.... please push this out... 

Comment 23 Peter Åstrand 2005-04-06 08:11:15 UTC
The update is available for FC2 and FC3 now. Thanks. 

However, I've discovered that the same problem exists in RHEL4. Should I open up
a new bug for this? Using the package util-linux-2.12a-23.i386 from FC3 seems to
work, but I assume that's not a supported solution. 

Comment 24 Peter Åstrand 2005-04-12 15:03:02 UTC
I've opened up a new bug for this issue on RHEL4:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154533