RedHat's (and any) NFS v3 impementation will indeed use a file handle on most operations, instead of a name. If you don't see the handle with wireshark, keep expanding parts of the packet until you find it. Some packets will contain a handle for the target object and for it's parent directory, so look at it carefully. On NFS CALLs, wireshark's summary "Info" line will often show a hash which is a shrunken down version of the handle. The problem is that without "other information" or access to the machine in question (for example, if you are analyzing someone else's packets), the file handle is not a very helpful piece of information.
You can search the packets which came before for the handle or it's hash, and hope that you can find some place where the same file handle is present in a way that associates it with a filename. For example, a lookup will result in a reply that contains the file's handle. Or the reply of a create operation will show the handle of the object which was just created. Or if a "readdirplus" sequence is present and packets were not truncated, you likely can get the information from there.
Or course, in many cases, the nfs mount has been in use for a while, and the original call which caused the client to "learn" the handle which goes with the name might be long gone. So if you are able to control and plan out the steps for problem reproduction and packet gathering, it can be helpful to begin without the nfs mount present. Then start tcpdump. Then perform the mount. Then reproduce the nfs problem. That way, you are sure to capture packets which will connect all file handles with file names.