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 [::]
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.
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.
David, please attach your git conf file.
David, also do you realize you have a fc4 bug on a fc6 blocker? You are testing
on fc6 right?
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?
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
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
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".
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).
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
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
(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.
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 ?
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
Apr 16 06:37:04 bombadil xinetd: attribute: flags should not be in
default section [file=/etc/xinetd.conf] [line=35]
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?
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:
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
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.