Let me contribute an observation on this bug.
The main cause of this bug is the setting "net.ipv6.bindv6only=1",
which is enforced by Debian in contradiction to the statement
made in the man page ipv6(7), the section about socket options
and IPV6_V6ONLY, as seen from the perspective of glibc.
The source code for inetutils-inetd is written to work with the
expected "net.ipv6.bindv6only=0", and there is no reason to expect
upstream to change their views. By the way, presently inetutils-1.8
is the valid release, so the Debian package is noticably lagging
behind.
Now, a simple patch, which is included below, will alter the source
to interpret "tcp", "udp" to imply a desire to open an IPv4 socket,
as seems to be expected by some Debian users. The price to pay is
that the service "inetutils-inetd" never will be able to open a
dual stacked listen socket for any service. Instead, "tcp" and "tcp6"
will both be needed to accomplish this. The patch in effect makes sure
that "tcp" and "tcp4" are synonyms; likewise for "udp" and "udp4".
A negative side effect is that any administrator who is relying on
inetutils-inetd to produce an IPv6 socket when using "tcp", he will
have a broken configuration.
The maintainer of this package will have to decide which drawbacks
are the hardest to accept: an everlasting patch to inetutils in
order to let "tcp" be used as openbsd-inetd interprets the protocol,
or leaving the source code intact, thus crippling inetutils-inetd,
since "net.ipv6.bindv6only=1" will presumably be in effect from
now onwards!
Best regards,
Mats Erik Andersson
--- inetutils-1.6.orig/inetd/inetd.c 2008-12-27 19:50:35.000000000 +0100
+++ inetutils-1.6/inetd/inetd.c 2010-08-31 11:59:19.000000000 +0200
@@ -1139,7 +1139,7 @@ getconfigent (FILE *fconfig, const char
#ifdef IPV6
/* We default to IPv6, in setup() we'll fall back to IPv4 if
it doesn't work. */
- sep->se_family = AF_INET6;
+ sep->se_family = AF_INET; /* Debian: Use IPv4 as default. */
sep->se_v4mapped = 1;
if ((strncmp (sep->se_proto, "tcp", 3) == 0)
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
