search

status-im / nimbus-eth2

Nim implementation of the Ethereum Beacon Chain
https://nimbus.guide
Other
546 stars 233 forks source link

can not bind to ipv6 address #2210

Open johannbarbie opened 3 years ago

johannbarbie commented 3 years ago

Describe the bug

when using --listen-address=<ipv6-address> node exits with error: Error: unhandled exception: /home/pi/nimbus-eth2/vendor/nim-chronos/chronos/transports/datagram.nim(488, 13) 'remote.family == local.family' [AssertionError]

To Reproduce Steps to reproduce the behavior:

  1. Platform details (OS, architecture): raspberry pi 4b, arm
  2. Branch/commit used: Nimbus beacon node v1.0.4-f06e6d46-stateofus
  3. Commands being executed: ./run-pyrmont-beacon-node.sh --listen-address=x:y:z:a:b:c:d:e
  4. Relevant log lines: 
INF 2021-01-04 12:26:53.336+01:00 Listening to incoming network requests     topics="beacnde" tid=21683 file=nimbus_beacon_node.nim:849
INF 2021-01-04 12:26:53.336+01:00 Starting discovery node                    topics="discv5" tid=21683 file=protocol.nim:802 node=71*99f03f:unaddressable bindAddress=x:y:z:a:b:c:d:e:9000 uri=enr:-Kq4QOpMoBA5hH83ZeClgUU2_Sb6TecWqiUcoAicY3Yc10ReFOKG2WG9ptFMpe4RSz8deQlR2hZ34GQxnCrZ-02krG4Bh2F0dG5ldHOI__________-EZXRoMpA7CIeVAAAgCf__________gmlkgnY0iXNlY3AyNTZrMaECwvD6_0ZObhhVX5jfg64ekn1QeItAIg9aWl241GD-UZaDdGNwgiMog3VkcIIjKA
INF 2021-01-04 12:26:53.336+01:00 No external IP provided, this node will not be discoverable topics="discv5" tid=21683 file=protocol.nim:806

Screenshots If applicable, add screenshots to help explain your problem.

Additional context

kdeme commented 3 years ago

IPv6 is currently not (fully) supported. As you have noticed, setting the listen-address to an ipv6 address will fail in the discovery implementation. It is on the TODO list to add also listening and sending on ipv6 (at least in discovery: https://github.com/status-im/nim-eth/issues/243) I'm not sure on the state of ipv6 support in libp2p currently (@dryajov ?)

Now, purely adding a listener on also ipv6, and sending data on ipv6 in case of ipv6 addresses in discovery is not that much work (making the whole configuration around it UX friendly however probably is). But if you truly have only an ipv6 address on your device, it would still give you much trouble as a lot of peers (most) might not be reachable over ipv6 (or at least not have it added in their ENR). You'd still need an ipv4 listener basically.

I don't know the in depth technical details of Dual-Stack Lite, but from what I understand it is ipv4 in ipv6 tunnelling, meaning your device still has ipv4 and ipv6 dual stack, but your CPE has only ipv6 and tunnels any ipv4 traffic through IPv6, which then gets NAT'ed on the service providers network end point(s) (CGN).

This would mean that you can still use ipv4 and should have such address (local however) available to listen on. Is that correct? You will probably not be reachable however as I doubt there is any "static" port forwarding available/done on that level, but I'm not sure about this.

dryajov commented 3 years ago

I'm not sure on the state of ipv6 support in libp2p currently (@dryajov ?)

libp2p relies on chronos for low level networking and (I believe) chronos has ipv6 support (@cheatfate?), the other part of this is multiaddress support (libp2p internal address representation), which is there but not very well tested. This certainly hasn't been a priority for us.

johannbarbie commented 3 years ago

This would mean that you can still use ipv4 and should have such address (local however) available to listen on. Is that correct?

correct

You will probably not be reachable however as I doubt there is any "static" port forwarding available/done on that level, but I'm not sure about this.

right, and I haven't found any way to request a port to be forwarded through the providers' NAT.