Created attachment 187202 [details] Fix nfsdumpstate client IP addr for IPv4 on 64bit and NFSv4.1 nfsdumpstate does not report the client IP address for the clientID. This can occur when: - The server is a 64bit architecture. This was caused by the code erroneously assuming that a "u_long" was a uint32_t and would exactly store an IPv4 host address. --> The attached patch fixes this. - The server didn't fill in the field for NFSv4.1 clients. --> The attached patch fixes this. - The client is using IPv6. This was not handled by the original NFSv4 code since the original RFC-3530 did not specify a way to define a IPv6 client callback address. --> I think that RFC-7530 addresses this and it needs to be fixed, but I don't have a patch yet.
A commit references this bug: Author: rmacklem Date: Sun Oct 15 22:22:28 UTC 2017 New revision: 324639 URL: https://svnweb.freebsd.org/changeset/base/324639 Log: Fix the client IP address reported by nfsdumpstate for 64bit arch and NFSv4.1. The client IP address was not being reported for some NFSv4 mounts by nfsdumpstate. Upon investigation, two problems were found for mounts using IPv4. One was that the code (originally written and tested on i386) assumed that a "u_long" was a "uint32_t" and would exactly store an IPv4 host address. Not correct for 64bit arches. Also, for NFSv4.1 mounts, the field was not being filled in. This was basically correct, because NFSv4.1 does not use a callback address. However, it meant that nfsdumpstate could not report the client IP addr. This patch should fix both of these issues. For IPv6, the address will still not be reported. The original NFSv4 RFC only specified IPv4 callback addresses. I think this has changed and, if so, a future commit to fix reporting of IPv6 addresses will be needed. Reported by: manu PR: 223036 MFC after: 2 weeks Changes: head/sys/fs/nfsserver/nfs_nfsdserv.c head/sys/fs/nfsserver/nfs_nfsdstate.c
Since I've committed the attached patch, I have marked in "In Progress". This patch still needs to be MFC'd and a separate patch that handles IPv6 needs to be done and MFC'd before this problem can be closed.
Created attachment 187274 [details] add ipv6 address for nfsdumpstate for NFSv4.1 mount This patch adds kernel support for IPv6 addresses for nfsdumpstate for NFSv4.1 mounts. Since the original NFSv4.0 RFC didn't specify IPv6, I think it would be best to least nfsdumpstate of handling for that out, as NFSv4.1 is preferred over NFSv4.0 now anyhow. There still needs to be a patch for nfsdumpstate.c to print out the IPv6 addresses. This patch will be added here soon.
Created attachment 187291 [details] modify nfsdumpstate to print out IPv6 client addresses This patch adds support to nfsdumpstate so that it will print out IPv6 addresses. Unfortunately, since IPv6 addresses are longer (more characters) than IPv4 ones, the field for them needs to be widened from 15->45chars. This results in a slightly different output format.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Regarding the patch to nfsdumpstate.c, wouldn't it be simpler to just use: > inet_ntop(dp[cnt].ndcl_addrfam, &dp[cnt].ndcl_cbaddr, ... That way, if there ever is any other address family support added in the future things will work "automatically"? (IPv8 with 128bit intergalactic addresses? :-) If there ever is any additional work on the dumpstate code, I have a few more things I'd really like to see included (but require changes to the data structure being passed between kernel and userspace)... - Remote port number - NFS protocol version - Local address and port number could be useful too.. (With remote port number in addition to (both IPv4 and IPv6) it would be easier to identify the specific TCP session from the output of 'netstat -Wan' for example...) (But without IPv6 support this is problematic anyway for us).
Well, ndcl_cbaddr is currently a union between IPv4 and IPv6 addresses. As such, any other address family is a bug and needs to be caught. (To add any other address family requires that the structure be rev'd, with a new variant of syscall, compatibility code for the old/current structure, etc. I'm retired now and can comfortably say I won't see IPv8.;-) As for the other suggestions, nfsdumpstate dumps NFSv4 lock state (and the clientid the lock state is associated with). It has nothing to do with what TCP address the RPCs are being received from (except for cheat I put in for NFSv4.1). In NFSv4.0, the client specifies a callback address that the server is to use to connect to the client and do callbacks. This address might be different from what the client's "from address(es)" used for TCP connections for RPCs to the server. --> This made doing callbacks through firewalls difficult to impossible. As such, for NFSv4.1, they defined what they called a backchannel, which was client->server TCP connection to be used for callbacks (can be the same TCP connection as used for client->server RPCs, but doesn't have to be). --> For NFSv4.1 there is no callback address. However, since the output of nfsdumpstate looked "broken" for NFSv4.1 since it didn't report any callback address...I cheated and put the "from address" of the TCP connection that could be used as a backchannel in there. TCP connections are handled by the KRPC and can change frequently (in theory for every RPC, although I wouldn't expect that in practice). Clients can trunk and use multiple TCP connections for a mount if they like. As such, the NFS server only knows the "from address" for an RPC while it is handling that RPC and doesn't track them. netstat should show TCP connections to port #2049, which are the NFSv3 and NFSv4 ones and beyond that, a packet trace in wireshark would show you the kind of information you are suggesting. Some day I need to set up IPv6 and test this patch, so I can put it in head and MFC it, rick.
A commit references this bug: Author: rmacklem Date: Sat Apr 13 21:45:45 UTC 2019 New revision: 346190 URL: https://svnweb.freebsd.org/changeset/base/346190 Log: Fix nfsdumpstate(8) so that it can print out INET6 callback addresses. The patch adds support for printing of INET6 callback addresses. It also adds the #ifdef INET, INET6 as requested by bz@. PR: 223036 Reviewed by: bz, rgrimes MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D19839 Changes: head/usr.sbin/nfsdumpstate/Makefile head/usr.sbin/nfsdumpstate/nfsdumpstate.c
A commit references this bug: Author: rmacklem Date: Sat Apr 13 22:00:09 UTC 2019 New revision: 346191 URL: https://svnweb.freebsd.org/changeset/base/346191 Log: Add support for INET6 addresses to the kernel code that dumps open/lock state. PR#223036 reported that INET6 callback addresses were not printed by nfsdumpstate(8). This kernel patch adds INET6 addresses to the dump structure, so that nfsdumpstate(8) can print them out, post-r346190. The patch also includes the addition of #ifdef INET, INET6 as requested by bz@. PR: 223036 Reviewed by: bz, rgrimes MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D19839 Changes: head/sys/fs/nfsserver/nfs_nfsdserv.c head/sys/fs/nfsserver/nfs_nfsdstate.c head/sys/modules/nfsd/Makefile
The patch that adds printing of INET6 callback addresses has been committed to head as r346290, r346191 and will be MFC'd. I think this PR can be closed once these commits are MFC'd.
A commit references this bug: Author: rmacklem Date: Thu Apr 25 21:25:32 UTC 2019 New revision: 346709 URL: https://svnweb.freebsd.org/changeset/base/346709 Log: Add support to nfsdumpstate for printing of INET6 addresses for locks. r346190 added support for printing of INET6 addresses for the "-o" option (all opens) but missed adding support for INET6 addresses for the "-l" option. This patch adds that support. PR: 223036 MFC after: 1 week Changes: head/usr.sbin/nfsdumpstate/nfsdumpstate.c
Patches for this have been committed and MFC'd.