rsync 2.6.2 --daemon Problem

Gregory Symons gsymons at
Wed May 5 18:44:49 GMT 2004

On Wed, 2004-05-05 at 04:02, Paul Slootman wrote:
> > I haven't really done any network programming, so I'm not exactly sure what's going on
> > in this section of the code, but it looks like rsync tries to set a flag on the IPV6
> > socket indicating that its only to be used for IPV6. In this case the IPV6 socket is for
> Setting that flag appears to fail on your system, because no IPV6 is
> available perhaps? (It works on mine...)
> If that's the root cause of the problem, skipping the IPV6 socket when
> that call fails should suffice. Try the followng patch.

That patch solves the problem. However, the weird thing is that my
system _does_ have IPV6 available:

root at taliesin # ls /proc/sys/net
802  core  ethernet  ipv4  ipv6  token-ring  unix

So it would seem to me that we're really just solving a symptom here. Of
course, more error handling never seems wrong to me:)

A quick search on google for ipv6 programming found this:

IPV6_V6ONLY socket option implementation by kernel versions

But in Linux, IPV6_V6ONLY socket option does not exist in kernel2.4.20
or earlier, except for USAGI kernels. Therefore, you can't do a bind(2)
of IPv4/IPv6 wildcard address to the same port. Therefore, you would
bind(2) only IPv6 wildcard address, and handle IPv4 traffic via
IPv4-mapped address with the same socket.


And I am indeed running a 2.4.20 kernel. So maybe the configure script
needs to detect whether or not this flag is actually available (which I
thought was the point of the #ifdef), rather than trusting the fact that
the macro itself is defined. Otherwise, if IPV6 _is_ available, but
IPV6_IPV6ONLY option is not, using the patch you sent would cause us to
skip any IPV6 addresses that we want to bind to.


More information about the rsync mailing list