Bug 122294 - autofs rpc_ping function always uses UDP
autofs rpc_ping function always uses UDP
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Depends On:
  Show dependency treegraph
Reported: 2004-05-02 15:05 EDT by Dan Morrill
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-05 10:13:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
rpc ping program which tests for nfs v2 and nfs v3 (1.63 KB, text/plain)
2004-05-13 08:55 EDT, Jeffrey Moyer
no flags Details

  None (edit)
Description Dan Morrill 2004-05-02 15:05:34 EDT
Description of problem: 
I have a small home network including an NFS disk server and a couple 
desktops which use autofs via /etc/auto.misc to mount the NFS server. 
All boxen are on FC2 test 3 (I'm brave.) My auto.misc entry is this: 
	alexopt  -rw,nfsvers=3,tcp  alex:/opt 
Key features: nfsvers=3, and tcp-only.  Meanwhile the NFS server 
itself has open only the specific ports for mountd, rpc, and NFS.  
(i.e. rpc/111, nfs/2049, and mountd/10002 after hard-coding 
in /etc/sysconfig/nfs.) 
This command works fine: 
	mount -t nfs -rw -o nfsvers=3,tcp alex:/opt /mnt/foo 
Mount is successful, **whether firewall on NFS server is running or 
However, the autofs config above fails, *if and only* if the firewall 
is running on the NFS server.  After some exploration and toying with 
the firewall rules on the server I discovered that when autofs 
attempts to mount /misc/alexopt, it is trying to use UDP to port 111. 
The NFS firewall has UDP ports shut, but the default firewall rule is 
a -j REJECT with icmp-host-prohibited, which autofs interprets as a 
"host is down" failure and then dies.  If I disable the firewall on 
the NFS server or allow the server to return a normal error to the 
UDP request, autofs proceeds to try TCP. 
In a nutshell, autofs is defaulting to UDP, and if that fails, it 
tries TCP. I can only conclude from this that autofs is ignoring or 
dropping the "tcp" option to it.  "noudp" doesn't help.  Depending on 
how the firewall on the NFS server is configured, autofs will either 
fail on UDP and try to use TCP (which succeeds,) or else it will 
conclude that the server is down and fail. 
Version-Release number of selected component (if applicable): 
I just upgraded to FC2 test 3 yesterday, so whatever's in that. 
How reproducible: 
Steps to Reproduce: 
1. Configure NFS server to use TCP-only NFSv3 and to have only 
   TCP ports 111, 2049, and 10002 (for mountd open) 
2. Test mount command above: success 
3. Test autofs config above: fail 
4. Disable firewall on server, re-test autofs: success 
5. Add a -j LOG rule to NFS firewall, restart firewall, retest 
   autofs:  failure, but this time it logs the UDP attempt
Comment 1 Jeffrey Moyer 2004-05-03 11:23:29 EDT
When checking to see if a host is available, the autofs4 code tries to
do an RPC ping using UDP.  This just calls function 0, and then checks
the latency of the test.  So, your firewall scripts should be reworked
to allow this packet through.

Please let me know if this works for you.

Comment 2 Dan Morrill 2004-05-03 15:26:23 EDT
That's consistent with what I am seeing, and yes letting UDP in does 
work.  However, I would call that behavior a bug.  Here's my 
1. If I added the "tcp" option to the autofs config line, I wasn't 
just kidding around;  I don't want it using UDP. :)  I realize that's 
for the NFS mount and not for RPC, but still... NFS honors it, why 
doesn't autofs? 
2. If I can mount the same NFS export directly from command line and 
THAT doesn't require an RPC ping over UDP, then why does autofs? I 
mean, what's it going to do? Refuse to perform the mount if the 
latency is over a certain amount? :) 
3. If the intent of the RPC ping is just to see if the host is up or 
not (i.e. latency isn't the ultimate goal) then if the "tcp" option 
is set (or alternatively, perhaps "noudp") I would argue for a TCP 
As a disclaimer, I don't really know why autofs is doing the ping in 
the first place.  I suppose it could be using the latency to select a 
rsize/wsize or cache or something equally exotic, but that would 
be... well, exotic.  So, maybe I'm just ignorant, but it seems like 
this is weird behavior for a tool which is just shorthand for 
But either way, tweaking the firewall rule does work.  If you choose 
to close the bug, then perhaps a note in the documentation about this 
behavior is in order. (Unless one already is and I just forgot to 
RTFM. :) 
Comment 3 Jeffrey Moyer 2004-05-03 15:44:41 EDT
You make some valid points.  I will take this up with the author and
see what we can come up with.

FYI, the rpc_ping is a side effect of the replicated server
functionality.  It checks to see if each server in the list is alive,
and also for the latency to each server.  In this way, it can choose
the best server from which to mount.  This bit of code is generic, so
even if you only have one server listed, you go through this path.

Autofs itself, as you mentioned, in the end just calls mount.  As
such, it never has the need to interpret mount options.  You are
suggesting that autofs looks at the mount options to determine how it
should behave itself.  I'm not completely against this, but it is ugly.
Comment 4 Dan Morrill 2004-05-03 15:56:06 EDT
Ahhhh... neat.  I figured there was probably something I was missing 
about why autofs was even trying. 
Also a good point about parsing the mount options -- though I had 
assumed that autofs was already doing that.  (i.e. -fstype=foo is an 
argument to autofs, not to mount, so autofs has to extract at least 
that much.  Or so I assumed.) 
Anyway, a workaround exists, so...  thanks much. 
Comment 5 Jeffrey Moyer 2004-05-13 08:54:04 EDT
Hi Dan,

Could you try the latest test rpm from my people page?  It should take
the rpc_ping logic out of the non-multi mount case.

Also, I'll attach a test program here for you to run.  Please give it
a go and post the output to the bug report.  I'm interested in the
output from this program when your NFS server is configured for only TCP.


Comment 6 Jeffrey Moyer 2004-05-13 08:55:30 EDT
Created attachment 100210 [details]
rpc ping program which tests for nfs v2 and nfs v3

Compile with gcc rpcping.c -o rpcping

Run as rpcping <hostname>
Comment 7 Dan Morrill 2004-05-13 21:38:08 EDT
Thanks, Jeff!  
Here is the output of your rpcping.c program (gcc -g -Wall):  
[morrildl@eponymous morrildl]$ ./rpcpinger alex  
detected NFS V2 on host alex  
detected NFS V3 on host alex  
No more logs about unexpected UDP packets from the NFS server's  
Quick comment about rpcping.c, though: if the default firewall rule 
on the server is "-j DROP" intead of "-j REJECT --reject-with..." 
then rpcping (as you would expect) takes a while to timeout on the 
UDP requests since it gets no response at all.  AFAIR, the rule on 
Fedora if you select "high security" version of the firewall during 
install is (or was) "-j DROP";  you might want to be aware of this. 
Requiring NFS servers not to use DROP is probably reasonable though; 
I have no issue with it at least. 
Anyway, autofs 4.1.2-6 from /~jmoyer/autofs/fc2/4.1.2-6/i386/ mounts 
the NFS drive quite happily, no problem. 
Ship it! :) 
Thanks for your help! 
- Dan 
Comment 8 Dan Morrill 2004-07-27 19:46:25 EDT
I notice this (by that I mean the patched autofs you have on your
people page) hasn't made it into updates yet for FC2.  Will it be
included in FC3?


- Dan
Comment 9 Jeffrey Moyer 2006-04-05 10:13:33 EDT
This was fixed in FC-3;  any packages versioned 4.1.3-15 and later should work.

Note You need to log in before you can comment on or make changes to this bug.