<div dir="ltr">Okay, the proper fix would be to make socket_connect loop over the results from gf_resolve_ip6; provided that hints.ai_family is removed from that method. By removing the preferred family hint; getaddrinfo will return all ip-addresses for a hostname (both v4 & v6); which also fixes problems with hosts having multiple (v4 or v6) ip-addresses. If there would still be administrators that prefer ipv4 over ipv6 (when connecting to a peer that offers both) they should use gai.conf to alter the order from which those addresses would be tried in socket_connect.
<div><br></div><div>I have prepared an alternative patch which is a bit more simple but does the job; my rationale for these changes:</div><div><br></div><div>gf_resolve_ip6 should not accept a `family` filter; since we cannot know if ipv4 or ipv6 is preferable (esp. when using a hostname) we should return all matches; not just the ones that match only the (not-configurable default) ipv4 filter<br>
</div><div>socket_*_get_remote_sockaddr should use the result from af_inet_*_get_local_sockaddr to determine the family to use. Since we don't know this beforehand; the result is always better then the default (ipv4)<br>
</div><div><br></div><div>I have used glusterfs-3.5.0 + this patch + 'option transport.address-family inet6' and have successfully probed both a ipv6 AND ipv4 peer by both hostname and address. The only issue I see that could arise from this change is the earlier mentioned host with both ipv4 & ipv6. But the gai.conf should keep this configurable; and alternatively one could probe by IP directly.</div>
<div><br></div><div>Please let me know what you think!</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 10:06 AM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, Jun 06, 2014 at 09:26:12AM +0200, Sjon Hortensius wrote:<br>
> That is a very definite and clear statement, thanks! When searching for<br>
> gluster + ipv6; I found multiple people saying they have this working; or<br>
> it should just work (from as far back as 2011). I assumed the same code<br>
> should be in 3.5 and still be functional; but my assumption was incorrect.<br>
<br>
</div>There are some bugs filed that sound like the problem you are seeing:<br>
<br>
Bug 910836 - peer probe over ipv6 on ipv4/ipv6 network fails.<br>
Bug 922801 - Gluster not resolving hosts with IPv6 only lookups<br>
Bug 1070685 - glusterfs ipv6 functionality not working<br>
<br>
If you have additional information on issue, it'll be appreciated if you<br>
can add that. In case you have also noticed a different problem, please<br>
create a new bug for it.<br>
<br>
Some issues look relatively easy to solve. If that is indeed the case,<br>
don't hesitate to send patches. Of course, you're also welcome to send<br>
patches for complex bugs ;-)<br>
<br>
Thanks,<br>
Niels<br>
<div class=""><br>
><br>
> Thanks for clarifying; that saves me some debugging.<br>
><br>
> Sjon Hortensius<br>
><br>
><br>
> On Thu, Jun 5, 2014 at 8:07 PM, Justin Clift <<a href="mailto:justin@gluster.org">justin@gluster.org</a>> wrote:<br>
><br>
> > On 05/06/2014, at 4:20 PM, Sjon Hortensius wrote:<br>
> > > After a bit of a struggle to get glusterfsd to listen to ipv6; I am now<br>
> > having problems trying to get the servers to 'peer probe' each other.<br>
> > ><br>
> > > I have tried peer probe on a ipv6-only hostname and an ipv6 address; but<br>
> > there doesn't seem to be any progress.<br>
> > ><br>
> > > common-utils.c:248:gf_resolve_ip6 always returns ipv4 addresses for<br>
> > hostnames while passing an ipv6 address results in "getaddrinfo failed<br>
> > (Address family for hostname not supported)"<br>
> > ><br>
> > > I suspect this is caused by rpc_transport_inet_options_build which does<br>
> > "dict_set_str (dict, "transport.address-family", "inet");"; which I think<br>
> > should be "inet/inet6"<br>
> > ><br>
> > > Can anybody confirm or deny this? Might there be a way to override this<br>
> > from the configuration? If any further information is useful I'll be happy<br>
> > to supply it.<br>
> ><br>
> > From memory, IPv6 support is something we're working on for GlusterFS<br>
> > 3.6. It's probably not something we'd really recommend with the current<br>
> > releases. :(<br>
> ><br>
> > + Justin<br>
> ><br>
> > --<br>
> > Open Source and Standards @ Red Hat<br>
> ><br>
> > <a href="http://twitter.com/realjustinclift" target="_blank">twitter.com/realjustinclift</a><br>
> ><br>
> ><br>
<br>
</div>> _______________________________________________<br>
> Gluster-users mailing list<br>
> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
> <a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br></div>