Bug 195265 - xinetd doesn't listen on IPv6 by default.
xinetd doesn't listen on IPv6 by default.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xinetd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Safranek
Brock Organ
: Reopened
Depends On:
Blocks: 181490 IPv6Blocker F7Update
  Show dependency treegraph
 
Reported: 2006-06-14 12:47 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.3.14-12.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-18 12:39:28 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 David Woodhouse 2006-06-14 12:47:54 EDT
I created /etc/xinet.d/git to run git-daemon, and it seemed to listen only on
IPv4 by default; not IPv6.

I had to manually add 'flags = IPv6' to make it listen on [::]
Comment 1 Jay Fenlason 2006-06-16 11:23:41 EDT
I'm slightly confused.  If you don't tell xinetd that the daemon is 
ipv6-capable, it doesn't listen for ipv6 connections, but if you do, it does?  
That sounds like it's working correctly to me.  The bug would be in 
the /etc/xinetd.d/* files that don't enable ipv6 for ipv6-capable servers. 
Comment 2 David Woodhouse 2006-06-16 11:35:40 EDT
They don't have to specify that they're IPv4-capable. Why should they have to
specify that they're IPv6-capable?

In most cases, they're actually capable of neither -- they're only capable of
stdin and stdout. That's why they use xinetd.

xinetd should assume IPv6 capability by default, and perhaps there should be a
flag to tell it _not_ to listen on IPv6 for a given service.
Comment 3 Steve Grubb 2006-06-17 08:30:16 EDT
David, please attach your git conf file.
Comment 4 Steve Grubb 2006-06-17 09:58:08 EDT
David, also do you realize you have a fc4 bug on a fc6 blocker? You are testing
on fc6 right?
Comment 5 David Woodhouse 2006-06-17 10:39:55 EDT
service git
{
        disable = no
        socket_type     = stream
        wait            = no
        user            = nobody
        server          = /usr/bin/git-daemon
        server_args     = --base-path=/home/git --user-path=public_git
--export-all --syslog --inetd
        log_on_failure  += USERID
}


Yes, I've only reproduced this on FC4. Are you suggesting that it's already been
fixed in rawhide?
Comment 6 Steve Grubb 2006-06-18 20:52:07 EDT
OK, I think I have some of the issues sorted out. The ipv6 flag is to select
either IPv4 or IPv6 addresses when more than one is returned by a dns lookup.
You should not be using this for this particular problem.

The issue appears to be no bind statement. If you had a "bind = ::" in the
default section, all would be well. I traced through the code and see that what
is happening is that it is using INADDR_ANY. I think you are wanting
IN6ADDR_ANY_INIT.

I looked at Richard Steven's documentation for getaddrinfo and think there is a
chance that I might be able to determine if IPv6 is available that way. I need
to review the portability code to ensure it always returns INADDR_ANY and what
glibc returns when IPv6 is not available.

So, I think this is your real issue, not that Xinetd is not IPv6 capable. Its
the bind address should be IN6ADDR_ANY_INIT in some cases.

And no, I don't think rawhide has this fixed. Its just odd that a FC4 bug is
blocking FC6.
Comment 7 David Woodhouse 2006-06-19 03:24:36 EDT
I think the portable thing to do is listen on ::, then listen on INADDR_ANY
_too_. But accept a failure to listen on INADDR_ANY, because on _some_ systems
the IPv6 socket will also accept IPv4 connections and will prevent you from
listing on the IPv4 socket. I'm sure Uli's documentation will make this clear.

And yes, the issue has always been described as "xinetd doesn't listen on IPv6
by default", not "xinetd lacks IPv6 support". 
Comment 8 Joe Orton 2006-06-19 09:16:41 EDT
Simply adding "bind ::" to the defaults section in /etc/xinetd.conf as-shipped
doesn't seem to be enough to fix this, that breaks configurations with IPv6
forcibly disabled (via modprobe.conf). 
Comment 9 Steve Grubb 2006-06-19 09:57:43 EDT
David, the design of xinetd is 1 socket per service. I do not see this changing
anytime soon. I can make it prefer IN6ADDR_ANY_INIT over INADDR_ANY when that is
available, but I cannot make it do both in 1 service config at the moment. So, I
need to make sure I understand your request. Do you want:

1) Prefer IN6ADDR_ANY_INIT over INADDR_ANY when available   - or -

2) Multiple addresses per service config
Comment 10 David Woodhouse 2006-06-19 10:23:31 EDT
Choosing _one_ of :: or INADDR_ANY is fine for Linux, since listening on :: will
(normally) accept IPv4 connections. 

It's only if you want code to be portable to BSDs that you need to listen on
both, iirc.
Comment 11 David Woodhouse 2006-06-20 09:35:22 EDT
(contining from comment #10...)

See the IPV6_V6ONLY sockopt -- we default it to off, some BSDs default it to on
(and just turning it off might suffice there). I _think_ that OpenBSD refused to
implement it on 'security' grounds, so you still actually have to listen to both
:: and 0.0.0.0 there if you want to accept both IPv6 and Legacy IP connections.
Comment 12 Christian Iseli 2007-01-22 06:08:37 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 13 David Woodhouse 2007-04-16 06:47:55 EDT
Still not working in rawhide. I installed rsync and it's listening on IPv4 only.

I wasn't even able to add the 'IPv6' flag in the default section of
/etc/xinetd.conf:

Apr 16 06:37:04  bombadil xinetd[9666]: attribute: flags should not be in
default section [file=/etc/xinetd.conf] [line=35]
Comment 14 David Woodhouse 2007-05-06 07:00:27 EDT
Any progress on getting this fixed? do we need to manually add 'flags=IPv6' to
every file we put in /etc/xinetd.d through the whole distribution, to work
around this bug?
Comment 15 Jan Safranek 2007-05-17 04:45:12 EDT
I have checked it into CVS (devel) and built it. It will not be included in FC7
though (it's too late and this is not blocking bug). It should appear in rawhide
when FC7 gets released.

You can access the built RPMs in Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=6707
Comment 16 Jeremy Katz 2007-05-18 11:46:01 EDT
This should probably also get pushed as an update after F7 goes out.  

I'm going to drop it from the blocker list and move to F7Update
Comment 17 Fedora Update System 2007-06-18 12:39:25 EDT
xinetd-2.3.14-12.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

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