Date: Wed, 20 Feb 2019 08:00:15 -0700 From: Ian Lepore <ian@freebsd.org> To: BBlister <bblister@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: userland process rpc.lockd opens untraceable ports...is something wrong here? Message-ID: <877baa2abd2c062a389b88e66dd67f1fba032e93.camel@freebsd.org> In-Reply-To: <1550671337578-0.post@n6.nabble.com> References: <1550610819543-0.post@n6.nabble.com> <CAOjFWZ7kJoa-_EVBrLUwLrs9J7ERWqkRf4bZh_giQ4-NRrGS_w@mail.gmail.com> <7b44b3ce-9b96-e91b-b9ca-57100c784db7@sentex.net> <20190219220404.GA1668@troutmask.apl.washington.edu> <1550671337578-0.post@n6.nabble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2019-02-20 at 07:02 -0700, BBlister wrote: > After one suggestion on the questions list, I used the rpcinfo -p but this > does not print every unknown port. For example: > > # netstat -an | grep -E '874|815' > tcp4 0 0 *.815 *.* LISTEN > tcp6 0 0 *.874 *.* LISTEN > > sockstat reports ? > # sockstat | grep -E '874|815' > ? ? ? ? tcp4 *:815 *:* > ? ? ? ? tcp6 *:874 *:* > > rpcinfo -p reports just one port > # rpcinfo -p| grep -E '874|815' > 100021 0 tcp 815 nlockmgr > 100021 1 tcp 815 nlockmgr > 100021 3 tcp 815 nlockmgr > 100021 4 tcp 815 nlockmgr > > > The 874/tcp6 which belongs to rpc.lockd does not appear on this list. > Is rpcinfo only for IPv4 and if yes,what tool do I use for IPv6 ? > > > > > > The grand question is of course, is there any tool to actually locate the > processes that open ports and cannot be identified with sockstat? > > The second grand question. Why rpc.lockd is a different kind of process that > cannot be located from sockstat? Other RPC processes are found using > sockstat, as the following printing shows: > > # rpcinfo -p | grep 2049 > 100003 2 udp 2049 nfs > 100003 3 udp 2049 nfs > 100003 2 tcp 2049 nfs > 100003 3 tcp 2049 nfs > > > sockstat |grep 2049 > root nfsd 41279 5 tcp4 *:2049 *:* > root nfsd 41279 6 tcp6 *:2049 *:* > > > nfs is found using rpcinfo and also using sockstat. > > What rpc.lockd does and it is not found. After 25 years of sysadmin, I find > it very strange for Freebsd to not being able to trace a listening port to > an executable. The situation here is that the socket is neither opened by nor owned by any userland process. The rpc.lockd implementation is split into a kernel piece and a userland piece, and much of the work is done in- kernel. The in-kernel part of the code contacts the userland daemon part for help when it needs to. So the socket is created by the in-kernel part of lockd, and it is not tied to any file descriptor. Tools which report on userland processes use file descriptors to associate kernel resources with the processes that own them. In this case, it is the kernel itself that owns the socket, so it can't be reported as belonging to any userland process. If you're interested in poking around in the code involved, see nlm_server_main() in src/sys/nlm/nlm_prot_impl.c -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?877baa2abd2c062a389b88e66dd67f1fba032e93.camel>