Bug 41309 - xinetd doesn't have IPv6 not enabled
xinetd doesn't have IPv6 not enabled
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
http://www.bieringer.de/linux/IPv6/IP...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-18 12:20 EDT by Dan Anderson
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-18 12:23:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Anderson 2001-05-18 12:20:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)

Description of problem:
xinetd doesn't have IPv6 enabled. That is, it doesn't listen to IPv6
addresses, even though the RedHat Linux kernel is now IPv6-aware and
enabled with init.d scripts.

How reproducible:
Always

Steps to Reproduce:
1. Enable a service, such as "daytime" (port 13) as follows.
1a. In file /etc/xinetd.d/daytime, change "disable = yes" to "disable = no"
1b. Restart xinetd: /etc/init.d/xinetd restart

2. See if it's listening to IPv6 sockets:
	netstat -an -A inet6 |grep ':::13 '
	

Actual Results:  # netstat -an -A inet6 |grep ':::13 '

Expected Results:  # netstat -an -A inet6 |grep ':::13 '
tcp        0      0 :::13                   :::*                   
LISTEN      
udp        0      0 :::13                   :::* 

Additional info:

To enable,  add "--with-inet6" to the %configure line in the xinetd.spec
RPM file:

%configure --with-libwrap  --with-inet6

This enables xinetd to listen to BOTH IPv4 and IPv6 sockets.
This feature had been enabled in RPMs I built at:

ftp://dan.drydog.com/pub/linux/xinetd-2.1.8.9pre14-7+ipv6.i386.rpm
ftp://dan.drydog.com/pub/linux/xinetd-2.1.8.9pre14-7+ipv6.src.rpm

(it also fixes bug 38669)
Comment 1 Trond Eivind Glomsrxd 2001-05-18 12:24:29 EDT
Not a bug - I didn't enable it because I'm not confident in the way it does it,
and having IPv4 work without problems is much more important.

That said, I'm considering enabling it for now (in Rawhide).
Comment 2 Dan Anderson 2001-05-19 18:50:55 EDT
I just learned there's a problem with enabling IPv6 with xinetd.  If it's running in a IPv4-only kernel (one with ipv6 not compiled in and the module not loaded), xinetd will start, but it won't listen to anything (IPv4 or IPv6).

One can load the IPv6 module (or compile it in) and IPv4 services will work without any further IPv6 configuration.

So it sounds like the alternatives are:
1. leave things as it
2. xinetd code needs to be a little smarter or
3. the /etc/init.d/xinetd script could dynamically decide whether to load a special
xinetd daemon only when IPv6 is enable.d
Comment 3 Pekka Savola 2001-05-20 10:05:35 EDT
This also appears to be a FAQ item at http://synack.net/xinetd/ :

---
Q. No services start with IPv6! What's the deal?
A. When you compile IPv6 support in, all sockets are IPv6 sockets. If your
kernel doesn't understand what an IPv6 socket is, all attempts to create
sockets will fail, and no services will start. Only compile xinetd with
IPv6 support if your kernel supports IPv6.
---

In reality, this is just developer laziness.  The software could do
something like:

1) first check whether ipv6 binding works, if not, use AF_INET for bindings
2) "force" options could be given when starting xinetd, so that if ipv6 is
not available, fallback would not occur (e.g. -6, -4)
3) per-service binding should be controllable, with for example either with like:
   -  protocol= tcp (default) | tcp4 | tcp6 | tcp46 , or
   -  family  = inet4 | inet6 | unspecified (default)
Comment 4 Trond Eivind Glomsrxd 2001-05-20 15:36:47 EDT
I suggest you make the above suggestion on the xinetd mailing list
Comment 5 Pekka Savola 2001-07-21 15:12:42 EDT
The support is non-trivial to add, so a workaround would be preferable for now; see #49621 for
a possible approach.

Note You need to log in before you can comment on or make changes to this bug.