Enable PCP by default? #31663

issue darosior openend this issue on January 15, 2025
  1. darosior commented at 7:19 pm on January 15, 2025: member

    Centralize discussion around turning the natpmp setting to on by default.

    UPnP used to be turned on by default. It was turned off by default following numerous vulnerabilities found in miniupnpc. We recently got rid of the miniupnpc dependency by dropping the UPnP feature (https://github.com/bitcoin/bitcoin/pull/31130). In addition we implemented PCP with NAT-PMP fallback in house (https://github.com/bitcoin/bitcoin/pull/30043), safer protocols enabling the same NAT traversal feature to end users.

    We have unit tests for our in-house implementation of PCP/NAT-PMP on the way (https://github.com/bitcoin/bitcoin/pull/31022). Once we also have fuzzing coverage then it becomes reasonable to consider potentially enabling the feature by default. The upside of turning this feature on by default is, if most ISP default provided router support it by default, a much more diverse P2P network. The downside is an increased attack surface: a vulnerability affecting only listening nodes would now also expose people’s node at home.

    Compatibility matrix of our PCP/NAT-PMP support. If your router at home is not included in this list please consider testing and let me know the result. See below for testing instructions.

    Router PCP support NAT-PMP fallback support Is PCP/NAT-PMP support enabled by default on the router?
    Verizon default-provided router :x: ✅ ✅
    Spectrum’s “WIFI 6E router” ✅ N/A :x:
    CR1000A (Verizon FIOS) :x: ✅ ✅
    Arcadyan PRV3399B-B-LT (aka Livebox Fibra) :x: ? (did not fall back to NAT-PMP) :x: (but UPnP is)
    Astound ? ? ?
    Archer AX3000 Pro :x: ✅ ✅
    Archer AC1750 :x: ✅ ✅
    Archer AX1800 :x: ✅ ✅
    Unify Cloud Gateway Ultra ✅ N/A :x:
    Huawy Echolife HG8145V5 :x: :x: ?
    JCO4032 :x: ? (only tested with ipv6) :x:
    FRITZ!Box 7530 AX ✅ N/A :x:
    OPNSense ✅ N/A :x:
    openwrt / Turris OS ✅ N/A ?
    protonVPN port forwarding :x: ✅ :x:

    Testing instructions

    • Download the latest Bitcoin Core v29.0 release candidate
    • Start bitcoind on any network with the natpmp flag
    • Spot the lines mentioning “PCP”, “NAT-PMP”, “natpmp” or “port mapping”. The lines will show directly on startup, no need to wait for IBD or whatnot. The process can be stopped after seeing these logs.
    • Check if the port was successfully mapped, check if it worked immediately with PCP or if NAT-PMP fallback was necessary
    • (optional) in case of failure, check if you need to manually enable PCP support in your router’s configuration
    • (optional) in case of success, you could check if the node is publicly reachable for good measure
    • Stop bitcoind
  2. fanquake added this to the milestone 30.0 on Jan 15, 2025
  3. darosior commented at 7:24 pm on January 15, 2025: member
    To be clear i’m not suggesting we turn this option on by default in 29, this merely opens the discussion more formally than yesterday’s chat on IRC. And i started writing this mainly to centralize results of tests against various routers.
  4. sipa commented at 11:53 pm on January 16, 2025: member

    Works out-of-the box on an Archer AX3000 Pro router/modem (with NAT-PMP fallback):

     02025-01-16T21:58:50.803107Z [net] portmap: gateway [IPv4]: 192.168.0.1
 12025-01-16T21:58:50.804793Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 8333 from gateway 192.168.0.1
 22025-01-16T21:58:50.804834Z [net] pcp: Internal address after connect: 192.168.0.150
 32025-01-16T21:58:50.805718Z [net] pcp: Received response of 8 bytes: (scrubbed)
 42025-01-16T21:58:50.805736Z [net] portmap: Got unsupported PCP version response, falling back to NAT-PMP
 52025-01-16T21:58:50.805747Z [net] natpmp: Requesting port mapping port 8333 from gateway 192.168.0.1
 62025-01-16T21:58:50.806500Z [net] natpmp: Received response of 12 bytes: (scrubbed)
 72025-01-16T21:58:50.942274Z [net] natpmp: Received response of 16 bytes: (scrubbed)
 82025-01-16T21:58:50.942361Z [net:info] portmap: Added mapping natpmp:(scrubbed) -> 192.168.0.150:8333 (for 2400s)
 92025-01-16T21:58:50.942472Z [net] portmap: gateway [IPv6]: (scrubbed)
102025-01-16T21:58:50.945277Z [net] pcp: Requesting port mapping for addr (scrubbed) port 8333 from gateway (scrubbed)
112025-01-16T21:58:50.945308Z [net] pcp: Internal address after connect: (scrubbed)
122025-01-16T21:58:50.945891Z [net:warning] pcp: Could not receive response: Connection refused (111)

    And I am getting inbound connections.

  5. murchandamus commented at 11:12 pm on January 18, 2025: contributor

    I have an Archer AC1750.

    Starting with bitcoind -natpmp -daemon my debug.log shows:

    0…
12025-01-18T23:04:02Z Command-line arg: natpmp=""
2…
32025-01-18T23:04:17Z [net:info] portmap: Added mapping natpmp:(scrubbed):8333 -> 192.168.0.172:8333 (for 2400s)
4…

    And I also have inbound connections.

  6. willcl-ark commented at 10:18 am on January 22, 2025: member

    This does not seem to fully work for me on a Unifi Cloud Gateway Ultra. It does appear to get an ipv4 mapping, but then fails whilst trying to get an ipv6 version:

    02025-01-22T09:42:37Z [net] portmap: gateway [IPv4]: 10.0.0.1
12025-01-22T09:42:37Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 8444 from gateway 10.0.0.1
22025-01-22T09:42:37Z [net] pcp: Internal address after connect: 10.0.12.100
32025-01-22T09:42:37Z [net] pcp: Received response of 60 bytes: 0281000000000960000239cb000000000000000000000000545a494d8ff27697003ec7a30600000020fc20fc00000000000000000000ffffd99bba35
42025-01-22T09:42:37Z [net:info] portmap: Added mapping pcp:<redacted>:8444 -> 10.0.12.100:8444 (for 2400s)
52025-01-22T09:42:37Z AddLocal(<redacted>:8444,3)
62025-01-22T09:42:37Z [net] portmap: gateway [IPv6]: fe80::76:b28b:573f:adcc%3
72025-01-22T09:42:37Z [net] pcp: Requesting port mapping for addr 1111:1111::1 port 8444 from gateway fe80::76:b28b:573f:adcc%3
82025-01-22T09:42:37Z [net] pcp: Internal address after connect: 1111:1111::1
92025-01-22T09:42:37Z [net:warning] pcp: Could not receive response: Connection refused (111)

    Checking the “successfully” mapped ipv4 port does not find it open:

    0₿ nc -v -n -z <redacted> 8444
1nc: connect to <redacted> port 8444 (tcp) failed: Connection refused

    I suspect the router is to blame here, but I don’t have a tool test manually test UPnP functionality outside of bitcoin core so can’t confirm this suspicion.

    UPnP is disabled by default on the router, which includes an option to enable “secure mode” too (which didn’t help).

  7. Emzy commented at 6:15 pm on March 19, 2025: contributor

    I tested the PCP functionality with v29.0rc2.

    Started it like this on my m3 mac /Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -signet -natpmp=1 -debug=net

    Router is a FRITZ!Box 7530 AX with up to date firmware version 8.02.

    First I got this for ipv4:

    02025-03-19T17:13:52Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
12025-03-19T17:13:52Z [net] pcp: Internal address after connect: 192.168.99.114
22025-03-19T17:13:52Z [net] pcp: Received response of 60 bytes:[xxx]
32025-03-19T17:13:52Z [net:warning] pcp: Mapping failed with result NOT_AUTHORIZED (code 2)

    I needed to allow PCP in my router via: Internet > Permit Access > Port Sharing > Add Device for Sharing > Permit independent port sharing for this device After this it worked:

    02025-03-19T17:24:28Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
12025-03-19T17:24:28Z [net] pcp: Internal address after connect: 192.168.99.114
22025-03-19T17:24:28Z [net] pcp: Received response of 60 bytes: [xxx]
32025-03-19T17:24:28Z [net:info] portmap: Added mapping pcp:87.x.x.x:38333 -> 192.168.99.114:38333 (for 13s)

    I also checked from a public node to connect to this node on my LAN. And it worked fine.

    I have native ipv6 at home. But the ipv6 pinholing seems not to work. Maybe I router has no support for it. Also I can’t find a special setting apart from the Permit independent port sharing for this device.

    I see this in the log:

    02025-03-19T17:24:28Z [net] pcp: Requesting port mapping for addr 2001:x:x:x:x:x:x:x port 38333 from gateway fe80:x:x:x:x:x:x:x%14
12025-03-19T17:24:28Z [net] pcp: Internal address after connect: 2001:x:x:x:x:x:x:x
22025-03-19T17:24:28Z [net] pcp: Received response of 60 bytes: [xxx]
32025-03-19T17:24:28Z [net:warning] pcp: Mapping failed with result NOT_AUTHORIZED (code 2)
42025-03-19T17:24:28Z [net] pcp: Requesting port mapping for addr 2001:x:x:x:x:x:x:x port 38333 from gateway fe80:e:
5:3e37:12ff:fe12:ce12%14
62025-03-19T17:24:28Z [net] pcp: Internal address after connect: 2001:x:x:x:x:x:x:x
72025-03-19T17:24:28Z [net] pcp: Received response of 60 bytes: [xxx]
82025-03-19T17:24:28Z [net:warning] pcp: Mapping failed with result NOT_AUTHORIZED (code 2)
  8. darosior commented at 6:19 pm on March 19, 2025: member
    Thanks for testing!
  9. willcl-ark added the label Brainstorming on Mar 20, 2025
  10. willcl-ark added the label P2P on Mar 20, 2025
  11. rsafier commented at 2:12 am on March 22, 2025: none

    Router Model: CR1000A (Verizon FIOS) Platform: MacOS 15.3.2 Version: v29.0rc2 Successfully mapped via NAT-PMP, verified inbound connectable

    0bitcoind -natpmp -debug=net -listen=1 -maxconnections=60
1...
22025-03-22T01:48:33Z [net] portmap: Got unsupported PCP version response, falling back to NAT-PMP
32025-03-22T01:48:33Z [net] natpmp: Requesting port mapping port 8333 from gateway x.x.x.x
42025-03-22T01:48:33Z [net] natpmp: Received response of 12 bytes: [xxx]
52025-03-22T01:48:33Z [net] natpmp: Received response of 16 bytes: [xxx]
62025-03-22T01:48:33Z [net:info] portmap: Added mapping natpmp:x.x.x.x:8333 -> x.x.x.x:8333 (for 2400s)
7...
  12. frankomosh commented at 12:29 pm on March 23, 2025: none

    My home router model: Huawei EchoLife HG8145V5 GPON Terminal and I am using Linux (Ubuntu 24.04.2 LTS) Version tested is v29.0rc2 Test result : Failed - No PCP response, no IPv6 gateway detected

    0bitcoind29 -regtest -natpmp=1 -debug=net -maxconnections=60
1...
2[net] portmap: gateway [IPv4]: xxx.xxx.xxx.x
3[net] pcp: Requesting port mapping for addr 0.0.0.0 port 18444 from gateway xxx.xxx.xxx.x
4[net] pcp: Internal address after connect: xxx.xxx.xxx.xx
5[net:warning] pcp: Could not receive response: Connection refused (111)
6[net] portmap: Could not determine IPv6 default gateway

    Bitcoin core correctly detected my router and identified internal IP. However, could not respond to PCP request, hence IPv6 pinholding cannot proceed. Is there a way to get around this?

  13. darosior commented at 2:36 pm on March 23, 2025: member
    Thanks everyone for the testing so far. @frankomosh can you confirm the UPnP setting is enabled on your router? I want to differentiate between routers with UPnP disabled by default and those that don’t support PCP/NAT-PMP.
  14. frankomosh commented at 3:19 pm on March 23, 2025: none

    Thanks everyone for the testing so far. @frankomosh can you confirm the UPnP setting is enabled on your router? I want to differentiate between routers with UPnP disabled by default and those that don’t support PCP/NAT-PMP.

    I confirmed. UPnP its not enabled on my router

  15. darosior commented at 4:50 pm on March 23, 2025: member
    And if you do enable it does the port mapping works from bitcoind?
  16. frankomosh commented at 6:13 pm on March 23, 2025: none

    And if you do enable it does the port mapping works from bitcoind?

    unfortunately my ISP cannot allow me to change it, so I can’t conclusively perform this specific test

  17. santochibtc commented at 9:24 pm on March 23, 2025: none

    not working with a router Arcadyan PRV3399B-B-LT with UPnP enabled

    02025-03-23T21:09:32Z [net] portmap: gateway [IPv4]: x.x.x.x
12025-03-23T21:09:32Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 8333 from gateway x.x.x.x
22025-03-23T21:09:32Z [net] pcp: Internal address after connect: x.x.x.x
32025-03-23T21:09:32Z [net:warning] pcp: Could not receive response: Connection refused (111)
42025-03-23T21:09:32Z [net] portmap: Could not determine IPv6 default gateway
  18. i-am-yuvi commented at 10:12 am on March 25, 2025: contributor

    Router Model: JCO4032 System: MacOS Sequoia 15.2 Version tested: v29.0rc2 Result: Failed - No PCP response

     02025-03-25T10:04:47Z [net] pcp: Timeout
 12025-03-25T10:04:47Z [net] pcp: Retrying (1)
 22025-03-25T10:04:48Z [net] pcp: Timeout
 32025-03-25T10:04:48Z [net] pcp: Retrying (2)
 42025-03-25T10:04:49Z [net] pcp: Timeout
 52025-03-25T10:04:49Z [net] pcp: Giving up after 3 tries
 62025-03-25T10:04:49Z [net] portmap: gateway [IPv6]: fe80:...
 72025-03-25T10:04:49Z [net] pcp: Requesting port mapping for addr 2405:xxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 18444 from gateway xxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
 82025-03-25T10:04:49Z [net] pcp: Internal address after connect: 2405:xxx:xxxx:xxxx:xxxxx:xxxxx:xxxx:xxxx
 92025-03-25T10:04:50Z [net] pcp: Timeout
102025-03-25T10:04:50Z [net] pcp: Retrying (1)
112025-03-25T10:04:51Z [net] pcp: Timeout
122025-03-25T10:04:51Z [net] pcp: Retrying (2)
132025-03-25T10:04:52Z [net] pcp: Timeout
142025-03-25T10:04:52Z [net] pcp: Giving up after 3 tries
  19. willcl-ark commented at 10:17 am on March 25, 2025: member
    I plan to retest this with v28 to try and determine if this is a router issue, or incompatibility with the (new) implementation in v29.
  20. darosior commented at 7:21 pm on March 26, 2025: member
    Thanks everyone for the testing so far. @santochibtc don’t you have any mention of -natpmp in your logs after the PCP failure? It’s surprising that it wouldn’t fallback. Also, when you say “with UPnP enabled” do you mean you had to manually enable UPnP on your router? It was enabled by default?
  21. santochibtc commented at 8:53 pm on March 26, 2025: none
    @darosior No, There is nothing about natpmp in my log. UPnP was enabled by default
  22. laanwj commented at 8:05 am on March 27, 2025: member
    i’ve added protonVPN port forwarding to the table (see #32052 (comment) for details), they don’t support PCP at the moment but the NATPMP fallback works
  23. willcl-ark commented at 1:29 pm on March 27, 2025: member

    I plan to retest this with v28 to try and determine if this is a router issue, or incompatibility with the (new) implementation in v29.

    It appears that v28.1 does port map OK on my router:

    0$ ./bitcoin-28.1/bin/bitcoind -natpmp=1 -port=9654 -daemon=0 | rg pmp
12025-03-27T13:14:12Z Command-line arg: natpmp="1"
22025-03-27T13:14:17Z natpmp: Port mapping successful. External address = xx.xx.xx.xx:9654

    But v29rc1 does not:

     0$ bitcoind -natpmp=1 -port=9654 -daemon=0 -debug=net | rg pcp -C5
 12025-03-27T13:16:30Z [net:warning] pcp: Could not receive response: Connection refused (111)
 22025-03-27T13:16:30Z [net] pcp: Requesting port mapping for addr [IPV6_ADDRESS_1] port 9654 from gateway [IPV6_GATEWAY]%3
 32025-03-27T13:16:30Z [net] pcp: Internal address after connect: [IPV6_ADDRESS_1]
 42025-03-27T13:16:30Z [net] Added connection peer=0
 52025-03-27T13:16:30Z [net:warning] pcp: Could not receive response: Connection refused (111)
 62025-03-27T13:16:30Z [net] pcp: Requesting port mapping for addr [IPV6_ADDRESS_2] port 9654 from gateway [IPV6_GATEWAY]%3
 72025-03-27T13:16:30Z [net] pcp: Internal address after connect: [IPV6_ADDRESS_2]
 82025-03-27T13:16:30Z [net:warning] pcp: Could not receive response: Connection refused (111)
 92025-03-27T13:16:30Z [net] pcp: Requesting port mapping for addr [IPV6_ADDRESS_3] port 9654 from gateway [IPV6_GATEWAY]%3
102025-03-27T13:16:30Z [net] pcp: Internal address after connect: [IPV6_ADDRESS_3]
112025-03-27T13:16:30Z [net:warning] pcp: Could not receive response: Connection refused (111)
122025-03-27T13:16:30Z [net] pcp: Requesting port mapping for addr [IPV6_ADDRESS_4] port 9654 from gateway [IPV6_GATEWAY]%3
132025-03-27T13:16:30Z [net] pcp: Internal address after connect: [IPV6_ADDRESS_4]
142025-03-27T13:16:30Z [net:warning] pcp: Could not receive response: Connection refused (111)

    I don’t understand why (from the logs) it looks like v29rc1 is only trying for an ipv6 mapping either. I have both ipv4 and 6 interfaces active…

    0bitcoin-cli -netinfo

    … on v29rc1shows one ipv4 address, five ipv6 addresses (4 of which are ipv6 “privacy extensions” addresses), and one tor address.

    So I guess on my UniFi hardware, 29rc1 seems like a possible regression.

  24. laanwj commented at 1:50 pm on March 27, 2025: member

    @willcl-ark that log is missing some parts to be able to follow what is happening, can you query for all of natpmp:|pcp:|portmap:? Most importantly, does the log say anything about gateway [IPv4]? The important part to make sure here is that it finds the default gateway and tries to connect to it (and if so, what error it gets).

    (you can leave out the IPv6 part, it’s clear that it doesn’t support that)

    My guess would be that this router ignores the IPv4 PCP packet instead of triggering the NATPMP fallback though it’s not clear from this whether it’s trying to send at all.

  25. willcl-ark commented at 2:10 pm on March 27, 2025: member

    Seems I can find a default gateway with ip:

    0will@ubuntu in ~/bin : 🐍
1$ ip route | grep default | awk '{print $3}'
2
310.0.0.1
4
5will@ubuntu in ~/bin : 🐍
6$ ip -4 route show default | cut -d' ' -f3
7
810.0.0.1
  26. laanwj commented at 2:12 pm on March 27, 2025: member

    2025-03-27T13:54:46Z [net] portmap: Could not determine IPv4 default gateway

    Ok, that’s the problem. (feel free to remove the rest of the log again if you’re worried about redaction)

  27. willcl-ark commented at 2:39 pm on March 27, 2025: member

    OK the issue is something to do with Tailscale intercepting the netlink queries. Bringing down Tailscale and I can confirm that pcp on v29rc1 works!

    02025-03-27T14:34:51Z [net] portmap: gateway [IPv4]: 10.0.0.1
12025-03-27T14:34:51Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 9654 from gateway 10.0.0.1
22025-03-27T14:34:51Z [net] pcp: Internal address after connect: 10.0.12.100
32025-03-27T14:34:51Z [net] trying v2 connection 10.0.0.88 lastseen=0.0hrs
42025-03-27T14:34:51Z [net] Added connection peer=0
52025-03-27T14:34:51Z [net] pcp: Received response of 60 bytes: 0281000000000960000447080000000000000000000000006ca2949124693c96afc2dfd70600000025b625b600000000000000000000ffffd99bba35
62025-03-27T14:34:51Z [net] portmap: gateway [IPv6]: <IPV6_edd923ce>

    Is the port map request usually 0.0.0.0?:

    0pcp: Requesting port mapping for addr 0.0.0.0 port 9654

    I’d have thought it would be either my LAN or WAN address?

    There is still a version discrepancy when using Tailsacale, but I can’t look further into it until later on now.

  28. laanwj commented at 3:35 pm on March 27, 2025: member

    pcp: Requesting port mapping for addr 0.0.0.0 port 9654 I’d have thought it would be either my LAN or WAN address?

    No, that message is OK. For IPv4 it doesn’t know (nor care)* what the internal address is, so it requests 0.0.0.0 when calling the mapping function. This will figure out what the relevant internal IPv4 address (the one toward the gateway) and external IPv4 address (the one that the router will give us for the mapping) is.

    * For IPv6 it does need to care because pinholing works differently, with no NAT going on

  29. willcl-ark commented at 10:37 pm on March 27, 2025: member

    I’ve found that I find that I can detect a gateway (with both tailscale up or down) by doing a specific routing query for a non-0.0.0.0 address. I am not totally sure what tailscale is doing behind the scenes to hijack netlink requests for a route to 0.0.0.0, but it’s certainly interfering.

    When I tried to debug what was returned by the original query for 0.0.0.0/0 it appears that I was getting about 70 results, all from table 52, which is a tailscale table.

    I have got a patch which works for me on x64 Ubuntu: https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:pcp-gateway-detect

    This maps ipv4 and 6 successfully, even with tailscale up:

    02025-03-27T22:38:24Z [net] portmap: gateway [IPv4]: 10.0.0.1
12025-03-27T22:34:01Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 9654 from gateway 10.0.0.1
22025-03-27T22:34:01Z [net] pcp: Internal address after connect: [removed]
32025-03-27T22:34:01Z [net] pcp: Received response of 60 bytes: [removed]
42025-03-27T22:34:01Z [net:info] portmap: Added mapping pcp:[[removed]:9654 -> [removed]:9654 (for 2400s)
52025-03-27T22:34:01Z [net] pcp: Requesting port mapping for addr [removed] port 9654 from gateway [removed]
62025-03-27T22:34:01Z [net] pcp: Internal address after connect: [removed]
72025-03-27T22:34:01Z [net] pcp: Received response of 60 bytes: [removed]
82025-03-27T22:34:01Z [net:info] portmap: Added mapping pcp:[[removed]]:9654 -> [removed]]:9654 (for 2400s)
  30. laanwj commented at 7:15 am on March 28, 2025: member

    I have got a patch which works for me on x64 Ubuntu: https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:pcp-gateway-detect

    Neat! Please open a PR.

    To be fair, the auto-forwarding setup is meant for straightforward customer ISP cases. i think throwing up our hands and going “set up forwarding yourself because you obviously can do this (and know better what you want)” in the case of complex network setups and routing tables is fine. Especially in multi-homing setups. Not sure tailscale should be counted among that.

  31. Lagrang3 commented at 10:19 am on March 28, 2025: none

    Router: Archer AX1800 OS: Debian 12 Bitcoin: v29.0rc2 Result: success

    0$ bitcoind -natpmp=1 -debug=net
1...
22025-03-28T10:11:15Z [net] pcp: Received response of 8 bytes: [removed]
32025-03-28T10:11:15Z [net] portmap: Got unsupported PCP version response, falling back to NAT-PMP
42025-03-28T10:11:15Z [net] natpmp: Requesting port mapping port 8333 from gateway 192.168.0.1
52025-03-28T10:11:15Z [net] natpmp: Received response of 12 bytes: [removed]
62025-03-28T10:11:15Z [net] natpmp: Received response of 16 bytes: [removed]
72025-03-28T10:11:15Z [net:info] portmap: Added mapping natpmp:[removed]:8333 -> [removed]:8333 (for 2400s)
  32. willcl-ark commented at 10:28 am on March 28, 2025: member

    Neat! Please open a PR.

    Hmmm, further testing this morning reveals other potential (root-causes and) fixes. Seems that I have two other issues with the original code:

    1. Responses can be longer than 4096 bytes. I guess tailscale is filling them up!
    2. Sometimes the first RTA_GATEWAY response found (which we use) may not be for the default route (and may not support pinholing). This happens for me on IPV6 only

    An alternative fix therefore is to iterate over the full response, and filter for the default route:

    https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:pcp-default-multipart

    This change has more LoC but in some ways feels more robust to me than my previous one @laanwj do you have any approach-inclination between either i) querying a dummy route vs ii) the current query (NLM_F_DUMP) with a multi-part response handler + a filter for default routes?

  33. laanwj commented at 11:44 am on March 28, 2025: member

    Oh! Nice detective work. Didn’t really consider that, yes it’s definitely possible for routing tables to be larger than 4k. There should probably be some limit to avoid crash/OOM in case of unexpected OS behavior but it doesn’t need to be that low.

    do you have any approach-inclination between either i) querying a dummy route vs ii) the current query (NLM_F_DUMP) with a multi-part response handler + a filter for default routes?

    i have a slight preference for getting all information then sifting through that, because it keeps the approach most similar to FreeBSD (which shares the same function).

    Querying a specific route is more efficient (and more like the Windows GetBestRoute implementation). Which is good, but we probably want to avoid depending on Linux-specific behavior, and make the fix also work for FreeBSD.

  34. darosior commented at 1:37 pm on March 28, 2025: member
    @Lagrang3 thanks for the testing. I assume like other Archer routers it was enabled by default?
  35. Lagrang3 commented at 3:20 pm on March 28, 2025: none

    @Lagrang3 thanks for the testing. I assume like other Archer routers it was enabled by default?

    Yes. Out of the box.

  36. dunxen commented at 9:32 pm on April 1, 2025: contributor

    UnFi Dream Router (UniFi OS Version: 4.1.13)

    I enabled UPnP in the router settings (disabled by default) Started bitcoind -natpmp (v29.0rc2) and PCP works immediately with no NAT-PMP fallback.

    There are no issues in the logs for IPv4 and IPv6 mapping:

     02025-04-01T20:50:43Z [init] nBestHeight = 890445
 12025-04-01T20:50:43Z [initload] initload thread start
 22025-04-01T20:50:43Z [mapport] mapport thread start
 32025-04-01T20:50:43Z [txindex] txindex thread start
 42025-04-01T20:50:43Z [txindex] txindex is enabled at height 890445
 52025-04-01T20:50:43Z [txindex] txindex thread exit
 62025-04-01T20:50:43Z [initload] Loading 4005 mempool transactions from file...
 72025-04-01T20:50:43Z [torcontrol] torcontrol thread start
 82025-04-01T20:50:43Z [basic block filter index] basic block filter index thread start
 92025-04-01T20:50:43Z [basic block filter index] basic block filter index is enabled at height 890445
102025-04-01T20:50:43Z [basic block filter index] basic block filter index thread exit
112025-04-01T20:50:43Z [mapport] [net] portmap: gateway [IPv4]: 192.168.1.1
122025-04-01T20:50:43Z [mapport] [net] pcp: Requesting port mapping for addr 0.0.0.0 port 8333 from gateway 192.168.1.1
132025-04-01T20:50:43Z [mapport] [net] pcp: Internal address after connect: 192.168.1.x
142025-04-01T20:50:43Z [init] AddLocal([redacted_ipv6]:8333,1)
152025-04-01T20:50:43Z [init] Discover: redacted_ipv6
162025-04-01T20:50:43Z [init] AddLocal([redacted_ipv6]:8333,1)
172025-04-01T20:50:43Z [init] Discover: redacted_ipv6
182025-04-01T20:50:43Z [init] AddLocal([redacted_ipv6]:8333,1)
192025-04-01T20:50:43Z [init] Discover: redacted_ipv6
202025-04-01T20:50:43Z [initload] Leaving InitialBlockDownload (latching to false)
212025-04-01T20:50:43Z [init] Bound to 127.0.0.1:8334
222025-04-01T20:50:43Z [init] Bound to [::]:8333
232025-04-01T20:50:43Z [init] Bound to 0.0.0.0:8333
242025-04-01T20:50:43Z [init] Loaded 2 addresses from "anchors.dat"
252025-04-01T20:50:43Z [init] 2 block-relay-only anchors will be tried for connections.
262025-04-01T20:50:43Z [init] init message: Starting network threads…
272025-04-01T20:50:43Z [net] net thread start
282025-04-01T20:50:43Z [dnsseed] dnsseed thread start
292025-04-01T20:50:43Z [dnsseed] Waiting 300 seconds before querying DNS seeds.
302025-04-01T20:50:43Z [opencon] opencon thread start
312025-04-01T20:50:43Z [init] init message: Done loading
322025-04-01T20:50:43Z [msghand] msghand thread start
332025-04-01T20:50:43Z [addcon] addcon thread start
342025-04-01T20:50:43Z [mapport] [net] pcp: Received response of 60 bytes: <redacted hex string>
352025-04-01T20:50:43Z [mapport] [net:info] portmap: Added mapping pcp:<redacted_ipv4>:8333 -> 192.168.1.x:8333 (for 2400s)
362025-04-01T20:50:43Z [mapport] AddLocal(<redacted_ipv4>:8333,3)
372025-04-01T20:50:43Z [mapport] [net] portmap: gateway [IPv6]: [redacted_ipv6]%2
382025-04-01T20:50:43Z [mapport] [net] pcp: Requesting port mapping for addr [redacted_ipv6] port 8333 from gateway [redacted_ipv6]%2
392025-04-01T20:50:43Z [mapport] [net] pcp: Internal address after connect: [redacted_ipv6]
402025-04-01T20:50:43Z [mapport] [net] pcp: Received response of 60 bytes: <redacted hex string>
412025-04-01T20:50:43Z [mapport] [net:info] portmap: Added mapping pcp:[redacted_ipv6]:8333 -> [redacted_ipv6]:8333 (for 2400s)
422025-04-01T20:50:43Z [mapport] AddLocal([redacted_ipv6]:8333,3)
432025-04-01T20:50:43Z [mapport] [net] pcp: Requesting port mapping for addr [redacted_ipv6] port 8333 from gateway [redacted_ipv6]%2
442025-04-01T20:50:43Z [mapport] [net] pcp: Internal address after connect: [redacted_ipv6]
452025-04-01T20:50:43Z [mapport] [net] pcp: Received response of 60 bytes: <redacted hex string>
462025-04-01T20:50:43Z [mapport] [net:info] portmap: Added mapping pcp:[redacted_ipv6]:8333 -> [redacted_ipv6]:8333 (for 2400s)
472025-04-01T20:50:43Z [mapport] AddLocal([redacted_ipv6]:8333,3)
482025-04-01T20:50:43Z [mapport] [net] pcp: Requesting port mapping for addr [redacted_ipv6] port 8333 from gateway [redacted_ipv6]%2
492025-04-01T20:50:43Z [mapport] [net] pcp: Internal address after connect: [redacted_ipv6]
502025-04-01T20:50:43Z [mapport] [net] pcp: Received response of 60 bytes: <redacted hex string>
512025-04-01T20:50:43Z [mapport] [net:info] portmap: Added mapping pcp:[redacted_ipv6]:8333 -> [redacted_ipv6]:8333 (for 2400s)
522025-04-01T20:50:43Z [mapport] AddLocal([redacted_ipv6]:8333,3)
532025-04-01T20:50:43Z [initload] Progress loading mempool transactions from file: 10% (tried 401, 3604 remaining)
542025-04-01T20:50:43Z [initload] Progress loading mempool transactions from file: 20% (tried 801, 3204 remaining)
552025-04-01T20:50:43Z [initload] Progress loading mempool transactions from file: 30% (tried 1202, 2803 remaining)
562025-04-01T20:50:43Z [initload] Progress loading mempool transactions from file: 40% (tried 1602, 2403 remaining)
572025-04-01T20:50:43Z [initload] Progress loading mempool transactions from file: 50% (tried 2003, 2002 remaining)
582025-04-01T20:50:44Z [initload] Progress loading mempool transactions from file: 60% (tried 2403, 1602 remaining)

    However, the node remains externally unreachable which is strange. With a recent update to UniFi OS, I’ve enabled UniFi’s Zone-Based Firewall. I’ll check the syslogs and report back here if that was the culprit. Otherwise I’ll need to dig a little deeper.

    P.S. The above was run with tailscale enabled. Disabling tailscale does not affect reachability from external sources.

  37. achow101 commented at 6:16 am on April 17, 2025: member
    A user has reported their router is (probably) incompatible: https://bitcointalk.org/index.php?topic=5538256.msg65285896#msg65285896


darosior sipa murchandamus willcl-ark Emzy rsafier frankomosh santochibtc i-am-yuvi laanwj Lagrang3 dunxen achow101

Labels
Brainstorming P2P

Milestone
30.0

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: 2025-04-19 06:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me