Thursday, March 3, 2011

RPC Programs and Procedures(NFS) details

■ Requirement : RPC Programs and Procedures(NFS) details
■ OS Environment : Linux[RHEL 5]
■ Application: rpc
■ Resolution : 

RPC Programs and Procedures(RPC request Message) :

The RPC call message has three unsigned integer fields -- remote
program number, remote program version number, and remote procedure
number -- which uniquely identify the procedure to be called.
Program numbers are administered by a central authority
( Once implementors have a program number, they can
implement their remote program; the first implementation would most
likely have the version number 1. Because most new protocols evolve,
a version field of the call message identifies which version of the
protocol the caller is using. Version numbers enable support of both
old and new protocols through the same server process.

The procedure number identifies the procedure to be called. These
numbers are documented in the specific program's protocol
specification. For example, a file service's protocol specification
may state that its procedure number 5 is "read" and procedure number
12 is "write".

Just as remote program protocols may change over several versions,
the actual RPC message protocol could also change. Therefore, the
call message also has in it the RPC version number, which is always
equal to two for the version of RPC described here.

check :

RPC Reply Message :

The reply message to a request message has enough information to
distinguish the following error conditions:

(1) The remote implementation of RPC does not support protocol
version 2. The lowest and highest supported RPC version numbers
are returned.

(2) The remote program is not available on the remote system.

(3) The remote program does not support the requested version
number. The lowest and highest supported remote program version
numbers are returned.

(4) The requested procedure number does not exist. (This is
usually a client side protocol or programming error.)

(5) The parameters to the remote procedure appear to be garbage
from the server's point of view. (Again, this is usually caused
by a disagreement about the protocol between client and service.)

check :

Program Number Assignment :

Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart:

0 - 1fffffff defined by
20000000 - 3fffffff defined by user
40000000 - 5fffffff transient
60000000 - 7fffffff reserved
80000000 - 9fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved

>> The first group is a range of numbers administered by and
should be identical for all sites.
>> The second range is for applications peculiar to a particular site. This range is intended
primarily for debugging new programs. When a site develops an
application that might be of general interest, that application
should be given an assigned number in the first range. Application
developers may apply for blocks of RPC program numbers in the first
range by sending electronic mail to "".
>>The third group is for applications that generate program numbers dynamically. The
final groups are reserved for future use, and should not be used.

You can capture the tcpdump and analysis it by wireshark.

nfs server daemons:

rpc.mountd, rpc.nfsd
rpc.statd, rpc.lockd (if necessary), and rpc.rquotad

nfs client daemons :

portmap, lockd, and statd

check : rpcinfo -p


No comments:

Post a Comment