IPv6 and Gulden

[thariley]

Describe the issue

When configuring an Ubuntu with IPv6 only and no IPv4 (only on loopback device which has 127.0.0.1 and ::1) the RPC won't start and block won't sync.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Configure the used network interface to only have IPv6 (zero IPv4 configuration)
2. Start GuldenD

RPC only seems to bind to 127.0.0.1 when:

• IPv4 address is configured
• IPv4 and IPv6 is configured
• But not on IPv6 only

Expected behaviour

If IPv4 is configured, it should work on IPv4 (which it does)
If IPv4 and IPv6 is configured, both should work
If IPv6 only, it should work

Actual behaviour

With IPv6 only in the debug.log or putting onlynet=ipv6 in .Gulden/Gulden.conf:
Binding RPC on address 127.0.0.1 port 9232 failed.
Loading addresses from DNS seeds (could take a while)
0 addresses found from DNS seeds
Adding fixed seed nodes as DNS doesn't seem to be available.

With IPv6 and IPv4 (without IPv4 gateway) so it has only IPv6 capable internet connectivity:
RPC starts
debug.log: 74 addresses found from DNS seeds
Won't sync, probably because it want's to connect to an IPv4 address, but it can't because it has no IPv4 internet connectivity

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of Gulden are you using?

Gulden version v2.1.0.19

Machine specs:

• OS: Ubuntu 18.04 LTS

Any extra information that might be useful in the debugging process.

https://pastebin.com/raw/xwrrBFuq

[mjmacleod]

This is fixed in .21 pre-release and fix will be included in official .21 release and onward as well.

re-open if issue continues in these releases

[thariley]

Running 2.1.0.21, there still seems something weird with the RPC binding
Here are 3 tests

Test 1: Dual stack, bind the RPC only to [::1]:9232
Interface configuration
loopback: IPv4 (127.0.0.1) IPv6(::1)
eth0: IPv4 (192.168.x.x) IPv6 (1:2:3:4:5:6:7:8)

Gulden configuration:
rpcbind=[::1]:9232

After starting gulden, it binds on the localhost both IPv4 and IPv6, while it should only have been IPv6:
:~$ netstat -an | grep 9232
tcp 0 0 127.0.0.1:9232 0.0.0.0:* LISTEN
tcp6 0 0 ::1:9232 :::* LISTEN

Test 2: IPv6 only (1/2), bind the RPC only to [::1]:9232:
Interface configuration
loopback: IPv4 (127.0.0.1) IPv6(::1)
eth0: IPv6 (1:2:3:4:5:6:7:8)

Gulden configuration:
rpcbind=[::1]:9232

After starting gulden
debug.log:
2019-11-30 12:21:07 libevent: getaddrinfo: address family for nodename not supported
2019-11-30 12:21:07 Binding RPC on address 127.0.0.1 port 9232 failed.

Gulden-cli:
$ gulden/Gulden-cli getinfo
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

Although it does listen on [::1]:9232
$ netstat -an | grep 9232
tcp6 0 0 ::1:9232 :::* LISTEN

Test 3: IPv6 only (2/2), bind the RPC to [::1]:9232 and 127.0.0.1:9232:
Interface configuration
loopback: IPv4 (127.0.0.1) IPv6(::1)
eth0: IPv6 (1:2:3:4:5:6:7:8)

Gulden configuration:
Nothing configured for rpc

The results are the same as test 2:

debug.log:
2019-11-30 12:27:01 libevent: getaddrinfo: address family for nodename not supported
2019-11-30 12:27:01 Binding RPC on address 127.0.0.1 port 9232 failed.

Gulden-cli:
$ gulden/Gulden-cli getinfo
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

Netstat:
$ netstat -an | grep 9232
tcp6 0 0 ::1:9232 :::* LISTEN

Expected behavour:
Test 1: RPC binding should only have binded on [::1]:9232
Test 2: RPC binding should only have binded on [::1]:9232
Test 3: I think the RPC should have binded on both 127.0.0.1:9232 and [::1]:9232, but it can also be 1 of the 2

[mjmacleod]

This is complicated a bit by the fact that we don't handle the RPC socket code ourselves but use libevent.

libevent does seem to have some flags in some of its calls to set v6only for v6 sockets, however the call we are using evhttp_bind_socket_with_handle does not have this - code will need to be refactored somewhat to properly fix this.