“netinfo” doesn’t show IPv6 “Local addresses” #30165

issue lcharles123 openend this issue on May 24, 2024
  1. lcharles123 commented at 2:00 am on May 24, 2024: none

    Is there an existing issue for this?

    • I have searched the existing issues

    Current behaviour

    “Local addresses” section of “netinfo” does not show the IPv6 addresses added using “externalip” config option. (Probably there is no announce of this addresses). Bitnodes.io show the version string of all IPs, but after put many of the IPv6 on active monitoring, only the first one specified with “externalip” are “UP” and the others are “UNREACHABLE”. (These are not my real addresses).

    root@debianpc:~# bitcoin-cli -netinfo ` Bitcoin Core client v27.0.0 - server 70016/Satoshi:27.0.0/

         ipv4   onion     i2p     npr   total   block
    in          0       1       0       7       8
    out         6       3       1       0      10       2
    total       6       4       1       7      18
    

    Local addresses 143.22.123.17 port 8333 score 27 qsddczpwthdeddm3viv4brhxbbxdm5eh5ywasdfmmaefctwrrgjdw5hmid.onion port 8333 score 4 awxyf6dvprtsssixojegfwjdn5xka62kpxecbwdovk23ohpqm.b32.i2p port 0 score 4 `

    Expected behaviour

    root@debianpc:~# bitcoin-cli -netinfo ` Bitcoin Core client v27.0.0 - server 70016/Satoshi:27.0.0/

         ipv4   onion     i2p     npr   total   block
    in          0       1       0       7       8
    out         6       3       1       0      10       2
    total       6       4       1       7      18
    

    Local addresses 143.22.123.17 port 8333 score 27 2006:f10:0:aa::234 port 8333 score 16 2006:f10:0:aa::111 port 8333 score 16 qsddczpwthdeddm3viv4brhxbbxdm5eh5ywasdfmmaefctwrrgjdw5hmid.onion port 8333 score 4 awxyf6dvprtsssixojegfwjdn5xka62kpxecbwdovk23ohpqm.b32.i2p port 0 score 4 `

    Steps to reproduce

    This is a very specific setup:

    1. In a machine A with no public IPv4 nor IPv6 address, start bitcoind with these options:

    #a public ipv4 and ipv6 address of another machine, let’s say machine B externalip=143.22.123.17 externalip=qsddczpwthdeddm3viv4brhxbbxdm5eh5ywasdfmmaefctwrrgjdw5hmid.onion externalip=2006:f10:0:aa::234 externalip=2006:f10:0:aa::111

    1. Now establish a reverse ssh tunnel from machine A to B on machine A, run: autossh -N -f -o “ExitOnForwardFailure=yes” -o “ServerAliveInterval=10” -o “ServerAliveCountMax=3” -R 143.22.123.17:8333:127.0.0.1:8333 root@IP_machine_B

    2. Test all the externalip’s using bitnodes.io, they shoud be reachable on the default port now. This configuration should provide IPv6 connectivity to the local node and the -netinfo should show the IPv6 announced using externalip config option (like it did with the public IPv4 specified).

    Relevant log output

    No response

    How did you obtain Bitcoin Core

    Pre-built binaries

    What version of Bitcoin Core are you using?

    v27.0.0

    Operating system and version

    Debian 11

    Machine specifications

    No response

  2. jonatack commented at 2:15 am on May 24, 2024: contributor
    Can you post the result of running ./src/bitcoin-cli getnetworkinfo on your machine (with the same modified IPs as above)? This is the information that -netinfo uses to fetch the local addresses.
  3. lcharles123 commented at 2:20 am on May 24, 2024: none
    root@debianpc:~# bcli getnetworkinfo { “version”: 270000, “subversion”: “/Satoshi:27.0.0/”, “protocolversion”: 70016, “localservices”: “0000000000000c09”, “localservicesnames”: [ “NETWORK”, “WITNESS”, “NETWORK_LIMITED”, “P2P_V2” ], “localrelay”: true, “timeoffset”: -8, “networkactive”: true, “connections”: 68, “connections_in”: 58, “connections_out”: 10, “networks”: [ { “name”: “ipv4”, “limited”: false, “reachable”: true, “proxy”: “”, “proxy_randomize_credentials”: false }, { “name”: “ipv6”, “limited”: true, “reachable”: false, “proxy”: “”, “proxy_randomize_credentials”: false }, { “name”: “onion”, “limited”: false, “reachable”: true, “proxy”: “127.0.0.1:9050”, “proxy_randomize_credentials”: true }, { “name”: “i2p”, “limited”: false, “reachable”: true, “proxy”: “127.0.0.1:7656”, “proxy_randomize_credentials”: false }, { “name”: “cjdns”, “limited”: true, “reachable”: false, “proxy”: “”, “proxy_randomize_credentials”: false } ], “relayfee”: 0.00001000, “incrementalfee”: 0.00001000, “localaddresses”: [ { “address”: “143.22.123.17”, “port”: 8333, “score”: 127 }, { “address”: “qsddczpwthdeddm3viv4brhxbbxdm5eh5ywasdfmmaefctwrrgjdw5hmid.onion”, “port”: 8333, “score”: 4 }, { “address”: “awxyf6dvprtsssixojegfwjdn5xka62kpxecbwdovk23ohpqm.b32.i2p”, “port”: 0, “score”: 4 } ], “warnings”: "" }
  4. jonatack commented at 4:00 pm on May 24, 2024: contributor

    Thanks @lcharles123 for the info.

    “Local addresses” section of “netinfo” does not show the IPv6 addresses added using “externalip” config option. (Probably there is no announce of this addresses).

    CLI -netinfo will only return the local addresses that are returned by RPC getnetworkinfo, as under the hood, -netinfo calls getnetworkinfo to fetch that info.

    Of the networks getnetworkinfo returns to you, IPv6 (and CJDNS, which is an IPv6 overlay network) are not reachable, which is why -netinfo isn’t showing ipv6 and cjdns columns.

    Perhaps IPv6 is blocked at some level in your environment, or the IPv6 IP needs to be specified in your ssh tunnel, I don’t know.

    Edit: probably not the issue, but did you try using the -discover config option?

    Bitnodes.io show the version string of all IPs, but after put many of the IPv6 on active monitoring, only the first one specified with “externalip” are “UP” and the others are “UNREACHABLE”.

    You may set multiple local addresses with -externalip, but the one bitcoind rumors to a particular peer will be the most compatible address (with some additional heuristics).

  5. lcharles123 commented at 2:44 am on May 25, 2024: none

    Edit: probably not the issue, but did you try using the -discover config option?

    Yes, but the addresses are unreachable anyway in local network, because the node are IPv4 only (and behind NAT).

    I guess I found the cause, because function AddLocal checks for connectivity on each -externalip entry using local interfaces, for IPv4 and others, its easy because it takes the normal way to the address. But there is no solution to reach v6 addresses on a machine v4 only without some config and external service. So a good modification on the code to allow adding the local v6 address can not be made. Or there is another way?

  6. willcl-ark commented at 12:20 pm on June 27, 2024: member

    Presumably in your setup your reverse SSH is connecting via ipv4, therefore bitcoind will detect it has an “active” (localhost) ipv4 connection and decide that its external ip address must be the one you gave it via the - externalip=143.22.123.17 option.

    OP reads to me that you want to have Node (A) bitcoind advertising both ipv4 and (an) ipv6 address(es) which are both reachable on Node (B), so that other nodes can connect to your node (A) via ipv4 or ipv6 on Node (B). Is that correct?

    The simplest solution of all IMO, is just to advertise ipv4 and ipv6 on Node (A), have them work and be externally connectable, then simply connect Node (B) to node (A) with a single, regular ipv4 connection. Why the need to advertise phantom addresses from one node via another? Just apply the setting on the node it applies to.

    In the case that you really need this other behaviour, Node (B) would have to proxy traffic from an ipv6 address to an ipv6 address on Node (A), perhaps using something like:

    0ssh -R [B's IPv6]:8333:[A's IPv6]:8333 user@B
    

    At that stage it might be better/easier to investigate something like this for nginx on Node (B):

     0# Node (B) nginx.conf
     1
     2server {
     3    listen 8333;  # IPv4
     4    listen [::]:8333 ipv6only=on; # IPv6
     5
     6    location / {
     7        # determine which address to proxy to
     8        set $backend_address "";
     9        
    10        if ($remote_addr ~ ":") {
    11            set $backend_address "[A's IPv6 address]";
    12        }
    13        
    14        if ($remote_addr !~ ":") {
    15            set $backend_address [A's IPv4 address];
    16        }
    17        
    18        proxy_pass http://$backend_address:8333;
    19    }
    20}
    

    If A cannot listen on ipv6 on your network, and you really want this setup, then you may need to forward B’s IPV6 traffic to a different ipv4 port on A, and investigate using iptables (or similar) to reroute traffic from that port to an internal-only IPV6 address.

    All that said, general bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange or the #bitcoin IRC channel on the Libera Chat network. And I think that would be the best place for the converstation to go from here.

    If you agree, I think we can close this issue at this point?

  7. willcl-ark added the label Questions and Help on Jun 27, 2024
  8. willcl-ark commented at 9:35 am on July 2, 2024: member

    OK I’m going to close this for now.

    Feel free to open a new issue or comment here if you are still experiencing this problem.

  9. willcl-ark closed this on Jul 2, 2024


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-30 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me