Bug 41309

Summary: xinetd doesn't have IPv6 not enabled
Product: [Retired] Red Hat Linux Reporter: Dan Anderson <redhatbugzilla>
Component: xinetdAssignee: Trond Eivind Glomsrxd <teg>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: pekkas
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO-3.html#xinetd
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-05-18 16:23:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Anderson 2001-05-18 16:20:48 UTC
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 16:24:29 UTC
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 22:50:55 UTC
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 14:05:35 UTC
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 19:36:47 UTC
I suggest you make the above suggestion on the xinetd mailing list

Comment 5 Pekka Savola 2001-07-21 19:12:42 UTC
The support is non-trivial to add, so a workaround would be preferable for now; see #49621 for
a possible approach.