[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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)


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

Reply to: