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.
I have prepared an alternative patch which is a bit more simple but does the job; my rationale for these changes:
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
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)
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.
Please let me know what you think!
On Fri, Jun 6, 2014 at 10:06 AM, Niels de Vos <ndevos@xxxxxxxxxx> wrote:
On Fri, Jun 06, 2014 at 09:26:12AM +0200, Sjon Hortensius wrote:There are some bugs filed that sound like the problem you are seeing:
> That is a very definite and clear statement, thanks! When searching for
> gluster + ipv6; I found multiple people saying they have this working; or
> it should just work (from as far back as 2011). I assumed the same code
> should be in 3.5 and still be functional; but my assumption was incorrect.
Bug 910836 - peer probe over ipv6 on ipv4/ipv6 network fails.
Bug 922801 - Gluster not resolving hosts with IPv6 only lookups
Bug 1070685 - glusterfs ipv6 functionality not working
If you have additional information on issue, it'll be appreciated if you
can add that. In case you have also noticed a different problem, please
create a new bug for it.
Some issues look relatively easy to solve. If that is indeed the case,
don't hesitate to send patches. Of course, you're also welcome to send
patches for complex bugs ;-)
Thanks,
Niels
> _______________________________________________
>
> Thanks for clarifying; that saves me some debugging.
>
> Sjon Hortensius
>
>
> On Thu, Jun 5, 2014 at 8:07 PM, Justin Clift <justin@xxxxxxxxxxx> wrote:
>
> > On 05/06/2014, at 4:20 PM, Sjon Hortensius wrote:
> > > After a bit of a struggle to get glusterfsd to listen to ipv6; I am now
> > having problems trying to get the servers to 'peer probe' each other.
> > >
> > > I have tried peer probe on a ipv6-only hostname and an ipv6 address; but
> > there doesn't seem to be any progress.
> > >
> > > common-utils.c:248:gf_resolve_ip6 always returns ipv4 addresses for
> > hostnames while passing an ipv6 address results in "getaddrinfo failed
> > (Address family for hostname not supported)"
> > >
> > > I suspect this is caused by rpc_transport_inet_options_build which does
> > "dict_set_str (dict, "transport.address-family", "inet");"; which I think
> > should be "inet/inet6"
> > >
> > > Can anybody confirm or deny this? Might there be a way to override this
> > from the configuration? If any further information is useful I'll be happy
> > to supply it.
> >
> > From memory, IPv6 support is something we're working on for GlusterFS
> > 3.6. It's probably not something we'd really recommend with the current
> > releases. :(
> >
> > + Justin
> >
> > --
> > Open Source and Standards @ Red Hat
> >
> > twitter.com/realjustinclift
> >
> >
> Gluster-users mailing list
> Gluster-users@xxxxxxxxxxx
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
diff -aur glusterfs-3.5.0-ORG/libglusterfs/src/common-utils.c glusterfs-3.5.0/libglusterfs/src/common-utils.c
--- glusterfs-3.5.0-ORG/libglusterfs/src/common-utils.c 2014-04-17 09:17:07.000000000 +0200
+++ glusterfs-3.5.0/libglusterfs/src/common-utils.c 2014-06-17 11:56:47.322942063 +0200
@@ -170,7 +170,6 @@
int32_t
gf_resolve_ip6 (const char *hostname,
uint16_t port,
- int family,
void **dnscache,
struct addrinfo **addr_info)
{
@@ -206,7 +205,6 @@
hostname);
memset(&hints, 0, sizeof(hints));
- hints.ai_family = family;
hints.ai_socktype = SOCK_STREAM;
#ifndef __NetBSD__
hints.ai_flags = AI_ADDRCONFIG;
diff -aur glusterfs-3.5.0-ORG/rpc/rpc-transport/rdma/src/name.c glusterfs-3.5.0/rpc/rpc-transport/rdma/src/name.c
--- glusterfs-3.5.0-ORG/rpc/rpc-transport/rdma/src/name.c 2014-04-17 09:17:07.000000000 +0200
+++ glusterfs-3.5.0/rpc/rpc-transport/rdma/src/name.c 2014-06-17 11:57:33.790985961 +0200
@@ -27,7 +27,6 @@
int32_t
gf_resolve_ip6 (const char *hostname,
uint16_t port,
- int family,
void **dnscache,
struct addrinfo **addr_info);
@@ -239,7 +238,6 @@
/* TODO: gf_resolve is a blocking call. kick in some
non blocking dns techniques */
ret = gf_resolve_ip6 (remote_host, remote_port,
- sockaddr->sa_family,
&this->dnscache, &addr_info);
if (ret == -1) {
gf_log (this->name, GF_LOG_ERROR,
diff -aur glusterfs-3.5.0-ORG/rpc/rpc-transport/socket/src/name.c glusterfs-3.5.0/rpc/rpc-transport/socket/src/name.c
--- glusterfs-3.5.0-ORG/rpc/rpc-transport/socket/src/name.c 2014-04-17 09:17:07.000000000 +0200
+++ glusterfs-3.5.0/rpc/rpc-transport/socket/src/name.c 2014-06-17 11:58:43.844702937 +0200
@@ -26,7 +26,6 @@
int32_t
gf_resolve_ip6 (const char *hostname,
uint16_t port,
- int family,
void **dnscache,
struct addrinfo **addr_info);
@@ -243,7 +242,7 @@
/* TODO: gf_resolve is a blocking call. kick in some
non blocking dns techniques */
ret = gf_resolve_ip6 (remote_host, remote_port,
- sockaddr->sa_family, &this->dnscache, &addr_info);
+ &this->dnscache, &addr_info);
if (ret == -1) {
gf_log (this->name, GF_LOG_ERROR,
"DNS resolution failed on host %s", remote_host);
@@ -515,9 +514,7 @@
ret = -1;
}
- if (*sa_family == AF_UNSPEC) {
- *sa_family = sockaddr->sa_family;
- }
+ *sa_family = sockaddr->sa_family;
err:
return ret;
@@ -597,9 +594,7 @@
break;
}
- if (*sa_family == AF_UNSPEC) {
- *sa_family = addr->sa_family;
- }
+ *sa_family = addr->sa_family;
err:
return ret;
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
