It is possible to open >1 connections to the same I2P node #21389

issue vasild openend this issue on March 8, 2021
  1. vasild commented at 5:19 pm on March 8, 2021: member

    Expected behavior

    addnode should not open a second connection even if the destination port is different for I2P nodes.

    Actual behavior

    A second connection is being opened even though ports are irrelevant and we actually connect to the same node two times.

    To reproduce

     0# Set up two I2P nodes A and B.
     1
     2node_a$ bitcoin-cli addnode bbb.b32.i2p:8333 onetry
     3# If we would try the same again it would not open a second connection,
     4# but trying on a different port does.
     5node_a$ bitcoin-cli addnode bbb.b32.i2p:8833 onetry # notice it is different port
     6node_a$ bitcoin-cli getpeerinfo |jq 'map(select(.network == "i2p")) |map({inbound: .inbound, addr: .addr, addrbind: .addrbind})'
     7[
     8  {
     9    "inbound": false,
    10    "addr": "bbb.b32.i2p:8333",
    11    "addrbind": "aaa.b32.i2p:8333"
    12  },
    13  {
    14    "inbound": false,
    15    "addr": "bbb.b32.i2p:8833",
    16    "addrbind": "aaa.b32.i2p:8333"
    17  }
    18]
    19
    20# Both connections are established, but in I2P ports are ignored,
    21# so we actually connected two times to the same node.
    22
    23# This is how it looks on the B's end:
    24
    25node_b$ bitcoin-cli getpeerinfo |jq 'map(select(.network == "i2p")) |map({inbound: .inbound, addr: .addr, addrbind: .addrbind})'
    26[
    27  {
    28    "inbound": true,
    29    "addr": "aaa.b32.i2p:8333",
    30    "addrbind": "bbb.b32.i2p:8333"
    31  },
    32  {
    33    "inbound": true,
    34    "addr": "aaa.b32.i2p:8333",
    35    "addrbind": "bbb.b32.i2p:8333"
    36  }
    37]
    
  2. vasild added the label Bug on Mar 8, 2021
  3. jonatack commented at 5:38 pm on March 8, 2021: member

    Yes, this might be similar to what I’ve been reporting from the field:

    Double connection from the same inbound peer around the same time:

    Screenshot from 2021-03-02 18-13-06

    idem, different peer, larger interval (56 minutes apart):

    Screenshot from 2021-03-05 01-59-28

    The inbound connections are probably all manual (addnode) ones.

  4. vasild referenced this in commit 4521677dfd on Mar 18, 2021
  5. vasild referenced this in commit 243919ea39 on Mar 19, 2021
  6. vasild referenced this in commit fccd5be1fa on Mar 19, 2021
  7. vasild referenced this in commit 18b6994851 on Mar 22, 2021
  8. vasild commented at 10:13 am on March 24, 2021: member
    Fix pending at #21514.
  9. vasild referenced this in commit 2f64c198a2 on Mar 30, 2021
  10. vasild referenced this in commit 4401bb56cf on May 31, 2021
  11. vasild referenced this in commit 71a294d77d on May 31, 2021
  12. vasild referenced this in commit 923a18ca0e on Jun 23, 2021
  13. vasild commented at 3:13 pm on June 23, 2021: member

    Possible approaches to resolve this:

    1. Merge #21514. It may cause problems if/when we start using SAM 3.2 which supports ports. But if we advertise ourselves as i2p:1234 and receive incoming connection with TO_PORT=5678 (!=1234) why not accept it? That is, maybe it would make most sense to keep ignoring ports even if using SAM 3.2. So #21514 may not cause problems in the future.

    2. Merge #22112. It would disrupt the nascent bitcoin-over-I2P network - a dozen nodes which run pre-release and are all known with port 8333. #22112 would silently stop connecting to all of them and even if they re-advertise themselves with same I2P address but port 0, that change will not be reflected in addrman which will keep the old entries with port 8333 to which we never connect.

    3. Extend #22112 to s/8333/0/ ports of I2P addresses in addrman. This would require re-bucketing in addrman.

    4. Do nothing and leave this issue unresolved.

  14. jonatack commented at 3:38 pm on June 23, 2021: member
    Thanks for the summary. It seems the first three options would best be chosen before v22 or not done at all. I suppose option 2 would mean deleting our peers.dat files for nodes already running an I2P service; we don’t have a hidden removepeeraddress rpc like the existing addpeeraddress.
  15. vasild commented at 4:03 pm on June 23, 2021: member

    It seems the first three options would best be chosen before v22 or not done at all.

    Yes, good point.

    deleting our peers.dat files

    What about adding a new p2p message which acts as a command to delete peers.dat from disk? Then we can remotely fix this without bothering the users?

  16. sipa commented at 4:07 pm on June 23, 2021: member

    What about adding a new p2p message which acts as a command to delete peers.dat from disk? Then we can remotely fix this without bothering the users?

    Are you serious?

  17. ghost commented at 4:18 pm on June 23, 2021: none

    What about adding a new p2p message which acts as a command to delete peers.dat from disk? Then we can remotely fix this without bothering the users?

    How would you ensure this is not exploited? Do we have already have any such p2p messages?

  18. vasild commented at 6:46 am on June 24, 2021: member
    Just kidding :rofl:
  19. vasild commented at 1:10 pm on June 29, 2021: member
    I implemented option 3 from the above list as the topmost commit in #22112.
  20. vasild referenced this in commit 0eafa9995f on Jul 1, 2021
  21. vasild referenced this in commit 386c51cbb1 on Jul 1, 2021
  22. vasild referenced this in commit 7bcfddc706 on Jul 2, 2021
  23. vasild referenced this in commit 7f02c66235 on Jul 5, 2021
  24. vasild referenced this in commit 4f432bd738 on Jul 9, 2021
  25. laanwj closed this on Jul 13, 2021

  26. laanwj referenced this in commit d8f1e1327f on Jul 13, 2021
  27. hebasto referenced this in commit a8d051e4ef on Jul 19, 2021
  28. jarolrod referenced this in commit 29bbf7b90d on Jul 19, 2021
  29. josibake referenced this in commit 8b987cf89c on Jul 21, 2021
  30. tryphe commented at 10:59 am on July 27, 2021: contributor
    This issue should be opened again re: #22559
  31. janus referenced this in commit b673a91645 on Nov 5, 2021
  32. Fabcien referenced this in commit 10df6b1378 on Feb 22, 2022
  33. DrahtBot locked this on Aug 18, 2022

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-18 18:12 UTC

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