search

muntorg / munt-official

Munt is a witness-secured decentralized network for payments, digital assets, finance and more
https://www.munt.org
Other
135 stars 46 forks source link

IPv6 and Gulden #183

Open thariley opened 4 years ago

thariley commented 4 years ago

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:

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:

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

https://pastebin.com/raw/xwrrBFuq

mjmacleod commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.