Re: ping and inetd
Marco d'Itri wrote:
On Aug 04, Noah Meyerhans <noahm@debian.org> wrote:
>If iputils-ping becomes the default, does that mean that ping6 should be
>installed by default, or should the package be split? Personally, since
I do not think there is any reason to split it.
>It seems that this version of inetd will create separate listening
>sockets for e.g. tcp4 and tcp6, even on the same service.
>Unfortunately, this won't work on Linux due to its lack of support for
>the IPV6_V6ONLY socket option. Basically, unless you're running the
>USAGI kernels, tcp6 in inetd.conf will behave the same as tcp46. This
>really needs to be documented.
I'll write a decent README.Debian before uploading it to main. Please
note that support for "tcp46" is implemented as an undocumented local
hack. My rationale is that without USAGI there is no way to properly
support tcp6 (while binding to the wildcard address) and with USAGI
tcp46 does not exist, so people should just use tcp6 or tcp4+tcp6
depending on their kernel.
>It seems to me that inetd could create only a single IPv6 socket, which
>would then listen for both IPv6 and v4 connections and pass them off to
This is what it does:
inetd 14737 md 4u IPv6 16928 TCP ip6-localhost:2222 (LISTEN)
inetd 14737 md 5u IPv6 16930 TCP *:2220 (LISTEN)
inetd 14737 md 6u IPv4 16932 TCP *:2224 (LISTEN)
inetd 14737 md 7u IPv6 16934 TCP *:2226 (LISTEN)
for
ip6-localhost:2222 stream tcp46 nowait md /usr/sbin/tcpd /usr/sbin/in.telnetd
2220 stream tcp46 nowait md /usr/sbin/tcpd /usr/sbin/try-from
2224 stream tcp4 nowait.3 md /usr/sbin/tcpd /usr/sbin/try-from
2226 stream tcp6 nowait md /usr/sbin/tcpd /usr/sbin/try-from
With a non-USAGI kernel there is no difference between tcp6 and tcp46.
FWIW, there has been some discussion about revising update-inetd to be
more modular and more accepting of other superserver configuration formats.
I offered to help because I want xinetd to have first class support in
Debian (mainly, to allow update-inetd to update it), but we have talked
somewhat about defining a generic update API that could support any
superserver (theoretically) by implementing a perl module that conforms
to the API.
Personally, I think that users should have the maximum choice possible;
we will have many people migrating from Red Hat/Mandrake where xinetd is
now the default, as well as commercial unices where "classic" inetd is
the default, and that users should be able to choose the superserver
they want and have update-inetd support it as transparently as possible.
This discussion is far from over, and I don't know how this new piece of
information affects it.
--
Martin Jackson: mhjacks -at- swbell.net
==================================
This message brought to you by Debian GNU/Linux 3.0 -- http://www.debian.org
A new 'chutist had just jumped from the plane at 10,000 feet, and soon
discovered that all his lines were hopelessly tangled. At about 5,000 feet,
still struggling, he noticed someone coming up from the ground at about the
same speed as he was going towards the ground. As they passed each other at
3,000 feet, the 'chutist yells, "HEY! DO YOU KNOW ANYTHING ABOUT
PARACHUTES?"
The reply came, fading towards the end, "NO! DO YOU KNOW ANYTHING
ABOUT COLEMAN STOVES?"
Reply to: