> Has anyone but me experienced that the new inetd with libwrap does no
> longer handle internal services, i.e. services, where inetd itself 
> generates the response?
>
> [ ... ]
> 
> I have seen this on NetBSD/i386 and NetBSD/mac68k.

I've seen it on NetBSD/alpha, just now.  8-)

The problem is the call:

        request_init(&req, RQ_DAEMON, sep->se_argv[0], RQ_FILE, ctrl, NULL);

on (or around) line 420 of inetd.

for internal services, sep->se_argv[0] will be NULL.


I don't understand why it doesn't use sep->se_service here rather than
sep->se_argv[0].  It seems both more logical and more correct that
you'd want to to set up your filter files based on the service name or
number given the the first column of inetd.conf, rather than the
argv[0] given for the argument.

I can imagine situations where you might want to allow access to a
service (i.e. program invocation) on some port by all hosts, but
disallow access by certain hosts to the same service on another
port...



chris