| Summary: | glusterfs 3.0.2 will not listen on IPv6 address | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Donald Neal <dmneal> |
| Component: | transport | Assignee: | Raghavendra G <raghavendra> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 3.0.2 | CC: | aavati, amarts, gluster-bugs, pavan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
PATCH: http://patches.gluster.com/patch/2861 in master (transport/socket: fix to valid_ipv6_address.) PATCH: http://patches.gluster.com/patch/2862 in release-2.0 (transport/socket: fix to valid_ipv6_address.) PATCH: http://patches.gluster.com/patch/2861 in release-3.0 (transport/socket: fix to valid_ipv6_address.) Cause 1 is fixed in 3.0.3rc1. Cause 2 isn't, so as shipped the code still doesn't listen on a specified IPv6 address. For the records, Communication with reporter of the bug:
Hi Donald,
This mail is related to bug,
http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=693
We are able to get the client and server working with ipv6 address. What was the scope of ipv6 address you were using? Is it link/global/site? The ipv6 addresses used should of scope "site". Can you test by using an ipv6 address in the scope "site"?
regards,
--
Raghavendra G
I'm using ULA addresses, which count as global scope.
ULA addresses are described in RFC4193. Site local addresses have been
deprecated since RFC3879 back in 2004.
I've installed 3.0.3 this morning. Again, this listens only on IPv4 addresses even if that's contrary to the configuration:
volume server
type protocol/server
option transport-type tcp
option transport.address-family inet6
option transport.socket.listen-port 6996
option transport.address <ULA>
option auth.addr.brick.allow fdd9:d076:b12b::1:*
subvolumes brick
end-volume
If no address is specified, but the address family is set as inet6, again only IPv4 addresses are used.
As before, this can be fixed by removing lines 105 to 108 of transport.c, which overwrite with "inet" whatever address family has been configured.
PATCH: http://patches.gluster.com/patch/3051 in master (libglusterfs/transport: no need to set address-family if one is not set in the configuration family.) PATCH: http://patches.gluster.com/patch/3052 in release-2.0 (libglusterfs/transport: no need to set address-family if one is not set in the configuration family.) PATCH: http://patches.gluster.com/patch/3050 in release-3.0 (libglusterfs/transport: no need to set address-family if one is not set in the configuration family.) |
Specifying an IPv4 address to listen on works just fine, as in volume server type protocol/server option transport-type tcp option transport.address-family inet option transport.socket.bind-address <IPv4 address> Specifying an IPv6 address does not. volume server type protocol/server option transport-type tcp option transport.address-family inet6 option transport.socket.bind-address <IPv6 address> Cause 1: valid_ipv6_address is rejecting valid IPv6 addresses. I suspect this is becuase at line 193 it's testing for the value of a pointer being NULL rather tha nthe content of the string pointed to being NULL. One answer would be to replace xlator.c line 193 if ((value > 0xffff) || (value < 0) || (endptr != NULL)) { with something like if ((value > 0xffff) || (value < 0) || (strlen(endptr) > 0 )) { Cause 2: The address-family is correctly stored as inet6, but transport_load is overwriting this with inet. I'm not sure why this code looks the way it does. I'm able to work with two different code sets for IPv4 and IPv6, so I've solved this by commenting out transport.c lines 105 to 108 if (is_tcp == 0) ret = dict_set_str (options, "transport.address-family", "inet"); but I hesitate to recommend this as a general-purpose fix. I'm doing this on Debian stable on x86_64, but I see nothing platform-specific here. - Donald Neal The University of Waikato