Chad Mynhier writes:
> On 10/1/07, Chad Mynhier <cmynhier at gmail.com> wrote:
> > I'd like to request a sponsor for
> > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6518130.
> >
> > Thanks,
> > Chad Mynhier
> > OS0124
>
> If anyone's curious about the details of my proposed solution, I've
> written up a fast-track which can be seen here:
> http://interstel.net/~mynhier/6518130.txt.
In general, I think it's great to see this sort of extension. It's
something we've needed for a long time.
Several comments on this:
- I haven't seen any discussion about this on networking-discuss.
I'd strongly recommend discussing the proposal there before
proceeding with integration.
- The materials don't mention the canonical tool for this job --
lsof. Why is that? I'd think that at least a feature comparison
or some hint about where we're headed would be in order. (Is this
just a stop-gap effort until lsof can be integrated, or are we
looking to subsume all of that functionality over time? If so, is
being different from other UNIX and Unix-like operating systems to
our advantage?)
- Technically, how will it work? Does it iterate over all processes
in user space, attaching to each one, then iterate over all open
files, determining what sort of descriptor each one is? If so, is
that the right way to do this? (We've long desired to have a
"return list of process IDs bound on these ports" sort of query in
IP's kernel interface, as it's needed by at *least* lsof and
identd.)
- What privileges are required in order to use the utility? How
would ordinary users examine their own networking applications?
- In order to integrate properly into Solaris, I believe that this
tool should support at least the standard transport layers, and
that means adding sctp. Supporting just tcp and udp isn't enough.
- It's also frequently necessary to look for processes holding open
an AF_UNIX socket. Could this tool eventually do that, or is it
only intended for use with AF_INET and AF_INET6? (Perhaps "pport"
isn't quite the right name.)
- Is distinguishing between "established" and "listening"
sufficient? If you need to distinguish these at all, then why not
allow for arbitrary tests against transport layer state? (It
would be quite nice indeed to obsolete the idea of grepping
through the unstable output of "netstat" as a way of locating
connections in a particular state.)
- What about raw sockets?
- What about remote port numbers? Would it be possible to look at
connections that have a given remote port connected, rather than
just looking at the locally bound port number?
- Are any tokens perhaps needed for "special" types of ports? Could
the tool distinguish between anonymous port bindings (kernel-
chosen) versus explicit bindings? How about the system's
configured privileged port list?
- How would you search by IP address or addresses or subnets?
- Would it be possible to search by a range of ports? For example,
searching for open X window displays by looking for ports in the
range 6000-6099.
- Does the proposed tool work with both TLI and sockets, or is it
sockets-only? Some applications still do use TLI, and the
existing pfiles command doesn't display them well at all. Try
running this command to see what I mean:
# pfiles `pgrep rpcbind`
- For the long term: Does it make sense to have this functionality
separate from pgrep? They seem to be doing similar things.
Perhaps, with suitable pgrep additions, there could even be a
family of independent tools that each filter lists of process IDs
on various criteria. Consider something like this:
# pgrep -U carlsonj | pport -p - 5000
... where the idea is to get a list of processes that I'm running
(using pgrep), and then use pport to winnow that list (read on
stdin via "-p -") down to just the processes with port 5000 open.
- There probably ought to be an mdb dcmd with a similar name and
equivalent functionality ("::pport").
- Perhaps just a nit: The text seems to imply that there can be only
one process listening on a given port. That's not true. If you
have a process listening on a port, and you call fork(2), you'll
then have two processes listening on the same port. There are
other ways for this to happen as well in certain contexts,
including SO_REUSEADDR.
- Nit: Would like to have a "-d" option, just like pgrep, so that
the output can be used with "ps -p".
- Nit: I assume that standard services(4) names can be used, right?
- Nit: "-v" probably shouldn't mean "show process name," as it means
"invert search criteria" for pgrep, and that'd be confusing for a
ptools utility. Instead, use "-l" if you need this feature. If
we had a "verbose" option, I think I'd prefer to see verbose
details about the socket that's held open, rather than details
about the process.
- Nit: I'd prefer to see lower-case command line option letters
rather than upper-case, when possible.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
