Bugzilla – Bug 127784
Provide option to listen on ipv6 socket if ipv6 available and fallback to ipv4 if not.
Last modified: 2005-11-03 08:52:33 UTC
There is IPv6 flag for xinet that makes it listen on ipv6 socket, but it fails to start the service when only ipv4 is available. Please provide an option to listen on ipv6 if avilable and fallback to ipv4 if not (just like ssh does by default).
Do you mean something like flags = IPv6orIPv4 meaning bind() to :::port; if that fails bind() to 0.0.0.0:port; OR flags = IPv6 IPv4 meaning bind() to :::port; bind() to 0.0.0.0:port; ? (Will talk to you when you're back from vacation)
The second seems better. bind() to ::: is enough, ipv6 sockets can accept ipv4 connections (thats the point of this enhancement). Currently when both the IPv6 IPv4 flags are set, xinetd warns and listens on ipv4 only, it would be best to change this to try bind to ::: and if that fails bind to 0.0.0.0.
Created attachment 56001 [details] patch allowing 'flags = IPv4 IPv6'
Does the above patch do what you want? Specify flags = IPv6 IPv4 # order doesn't matter and xinetd will first try to create an IPv6 socket and fallback to an IPv4 socket. BTW you can achieve the same by creating two services: service foo { id = foo-4 flags = IPv4 ... } service foo { id = foo-6 flags = IPv6 v6only = yes ... } So this patch might not be needed.
Right, this would work too. But the one socket solution is neat, it would be nice if it were accepted upstream, so we wouldn't have to use the two sockets or maintain the patch.
OK, so I'm setting this to FIXEd and will talk to upstream.
Seems like it will be accepted by upstream: On Tue, Nov 01, 2005 at 11:50:00AM +0100, Michal Marek wrote: > > Do you think this patch could make it info official xinetd? My initial reaction was negative, but after more thought and bouncing the idea off others, I think it's probably fine. Rob