nfsd over tcp not working

[henk baars]

I have a requirement to start nfsd over tcp. So according the man page of nfsd:
nfsd -p tcp num_nfsd.

nfsd starts fine, but no mounts can be made on any client with the error message:
nfs mount: getaddr_nfs: : NFS service not responding(retry delay=5s)
nfs mount: retry: retrying(1) for: /mnt after 5 seconds
nfs mount: retry: giving up on: /mnt

When I revert nfsd back to defaults everything works fine (and nfsstat shows that the connection is over tcp!).

showmount [nfs-server] works on the client, rpcinfo -T tcp [nfs-server] as well, rpcinfo [nfs-server] does not. I do see nfsd on tcp only instead nfsd over udp/tcp in the default case which makes sense.

Henk Baars

[RAC_1]

Have you started nfs.core on nfs server and nfs.client on client side? Is rpcbind running?

[henk baars]

yes, I did try that. It also works fine when starting nfsd without the -p tcp option. Systems are running HP-UX 11.11

[Dave Olker]

Hi Henk,

This is a known problem with HP's NFS/TCP start code. If you try to only start NFS/TCP it fails. If you start with the default options it registers both UDP and TCP. The lab knows about this problem.

Were you just trying to make sure NFS/TCP was started? If that's the case just use the default options and TCP support is on by default. If there is some reason why you're trying to forcibly *NOT* start UDP support please let me know the reasons.

I'd be curious why you need to forcibly disable UDP support - particularly when any NFS client has the ability to only request NFS/TCP at mount time. On HP-UX clients this is done with the -o proto=tcp option. On other clients it may be a different syntax, but every client I've seen allows you to forcibly select TCP as the transport. Also, the way most clients work is if you specify a protocol to use, like with a -o proto=tcp option, it will *only* use that protocol and if the requested protocol doesn't exist it will fail the mount rather than the default behavior of trying TCP first and then falling back to UDP if the TCP mount request fails.

Again, I'd be interested in any reasons you have for wanting to disable UDP support in your environment, assuming that was your goal.

Regards,

Dave

[henk baars]

Hi Dave

Thanks for your reply!. Basically the reason I want to do this is that we have a security baseline dictating this. I know that tcp is used anyway, but the security rule states explicitly I have to start it with nfsd -p tcp option and udp support must be disabled.

Their reasoning is, in short "We require TCP of nfsd because that is sufficient to prevent IP spoofing, which is easier with UDP than TCP." Note that the authors of the security baseline have no real experience with HP on the matter and as it defaults to TCP anyway I do think that should be enough.

If it is a known problem do you know if it will be fixed by the lab, and when? I do think that if it is a legitimate option of nfsd it should work as well.

Henk

[Dave Olker]

Hi Henk,

The defect number in the lab is JAGaf24414.

I don't believe the lab has any current plans to fix this defect on 11.11 or 11.23 because there are no customers requesting the fix.

We originally found this defect during internal testing. Internally found non-critical defects of this nature (i.e. not panics, data corruption, etc.) are typically fixed in the next release. That is the case with this defect - the current plan is to fix it in 11.31.

If you are not able to wait until 11.31 to get this fix, you should open a support call with HP and reference defect number JAGaf24414. They can add you as a customer requesting a fix for this defect. I can't guarantee the lab will fix this defect prior to 11.31, but as of now there are no customers asking for the fix prior to 11.31.

Regards,

Dave

[henk baars]

Hi Dave
thanks for the info. I think I will try to convince the security guys with this info that it is not sensible and if they still want it they have to wait.

Henk

[henk baars]

Valuable info on this subject, basically my conclusion is that we have to wait till 11.31 to get this option operational.