Testnet2 regression on same machine/network: Testnet2 syncs but reports ports closed / 0 incoming, while Testnet1 opens ports but stays at Joining SCP

[jurbizco]

Summary

I'm reporting a reproducible comparison on the same Windows PC, same router, same public WAN IP, same port forwarding, and same firewall path.

Environment

• OS: Windows
• Docker image: pinetwork/pi-node-docker:community-v1.0-p20.4
• Public WAN IP is public/routable (not private RFC1918 / not CGNAT)
• Router port forwarding confirmed
• Windows firewall rules added
• Bitdefender was removed during troubleshooting

Issue Detail

• Testnet2: Syncs successfully but consistently reports ports closed and shows 0 incoming connections.
• Testnet1: Opens necessary ports but remains stuck at "Joining SCP" and does not sync.

Steps taken

1. Both testnets tested on the same hardware and network settings.
2. Port forwarding rules verified and confirmed.
3. Bitdefender security suite uninstalled for troubleshooting.
4. Repeated firewall and Docker configuration checks.
5. Repeated restarts of both testnets and host machine. ------->What Pi officially says / current docs:

• Pi Node 0.5.0 moved Nodes toward Testnet2 and said the original Testnet could still be used “for now” but would soon be closed for Node use.
• The current official pi-node-docker image still accepts --testnet and --testnet2.
• The current official Docker image examples publish host ports 31401, 31402, and 31403.

Observed behavior on Testnet2:

• Container runs and can stay up
• Consensus can sync
• External port test from outside the home network shows port 31402 open
• However, the Pi app’s built-in checker reports:
  31400 NOT OPEN
  31401 NOT OPEN
  31402 NOT OPEN
  31403 NOT OPEN
  31404 NOT OPEN
  31405 NOT OPEN
  31406 NOT OPEN
  31407 NOT OPEN
  31408 NOT OPEN
  31409 NOT OPEN
• Pi app status on Testnet2 shows patterns like:
  Outgoing connections: 8
  Incoming connections: 0
  Supporting other nodes: No

Observed behavior on Testnet1 (manual comparison on same machine/network):

• I stopped testnet2 and launched the same image with:
  --testnet
• Testnet1 container starts successfully
• PostgreSQL, stellar-core, and horizon can all run
• Local API on 127.0.0.1:31401 returns HTTP 200
• External tests show ports 31401, 31402, and 31403 open from outside the home network
• However, stellar-core info stays at:
  state = Joining SCP
  ledger num = 1
  authenticated_count = 0
  pending_count = 0
• So Testnet1 starts and exposes ports, but does not actually join peers

Why I’m reporting this:
This comparison strongly suggests the local setup is not the root cause:

• same PC
• same router
• same WAN IP
• same forwarding
• same Windows firewall
• same Docker host

On the same setup:

• Testnet2 can reach a synced blockchain state but still reports ports closed / 0 incoming / not supporting other nodes
• Testnet1 opens ports and runs services, but does not join peers and stays at Joining SCP

This looks like either:

1. a Testnet2 port-check / status-reporting regression, and/or
2. a mismatch between the Pi app checker expecting 31400–31409 and the current official Docker image behavior/documented host port mappings.

Relevant references:

• Pi Node 0.5.0 transition to Testnet2, with original Testnet still usable “for now”
• Official pi-node-docker image supports --testnet and --testnet2
• Current Docker image examples publish 31401, 31402, 31403

Please clarify:

• For the current Docker image, which host ports are actually required for a healthy/supported Node on Testnet2?
• Is the Pi app checker still expected to require 31400–31409 for Nodes using the current Docker image?
• Is “Incoming connections: 0 / Supporting other nodes: No” on Testnet2 currently a known issue even when the node is synced and an external test confirms port 31402 is open?

I can provide screenshots / exact outputs if needed.

What this is based on:

Pi’s Node 0.5.0 announcement says Nodes were transitioning to Testnet2 and that the original Testnet could still be used “for now,” but would soon close for Node use.

The official pinetwork/pi-node-docker image currently supports both --testnet and --testnet2, and its current examples/documentation center on published host ports 31401, 31402, and 31403.

Similar user reports exist on Pi’s GitHub issues, including cases where only 31401–31403 appear open while incoming connections remain 0, and cases where the port listener/checker behavior conflicts with the consensus container state.

Additional Info

• Ports are confirmed open externally using online tools.
• All configurations and troubleshooting measures have been applied identically to both testnets.

Expected Behavior

• Both testnets should exhibit similar port and connection status given identical environments and configurations.

Actual Behavior

• Testnet2 syncs blockchain but shows 0 incoming connections and claims ports are closed.
• Testnet1 appears to have open ports but never moves past "Joining SCP".

Steps to Reproduce

1. Launch Testnet1 and Testnet2 using Docker on the same Windows machine.
2. Apply identical port forwarding and firewall rules.
3. Observe port and connection status in both nodes.

Logs / Screenshots

Please provide logs or screenshots if you need further evidence.

[Sidzeppelin95]

Yes, I see that when I click on troubleshooting. There're 8 outgoing ports but 0 incoming ports.

Maybe we need a portschecker or listener in order to make our connection in and out.
I did sync with the Blockchain but then I thought as it has been configured already, I don't have to keep downloading checkpoints anymore but then after opening my PC again, it started again. Does this mean it needs to be done continuously?