To check an xOne node's networking, run it as a read-only follower, then confirm four things: it advertises its public address, other nodes can reach it, it finds peers through a bootnode, and it refuses the peers you do not allow. The checks come from docs/ops/p2p-live-checklist.md in xOneRS, added in PR #990 (merged 2026-11-15).

Every check runs on a follower with no validator key and no --mine. The checklist uses $D for a new empty directory and $BIN for the xone binary. Most commands below are on main only: the v0.1.0 release has no xone p2p subcommand and no --permissions.nodes flag. For joining a network, see how to join net2040; for the checks a node runs on a peer's chain, see peer chain verification.

Does the node advertise its public address?

Start a follower on a public host with no --nat flag and read admin_nodeInfo after two minutes. Pass: the enode holds the host's public IP, not 127.0.0.1.

$BIN --network apothem --datadir $D --syncmode snap --http --http.addr 127.0.0.1 --http.port 8545 &
curl -s -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"admin_nodeInfo","params":[]}' http://127.0.0.1:8545

The node log holds advertised address now <ip> (discovery) once three or more peers agree. On main, --nat accepts any (the default: the IP that 3 or more discovery peers report), none (the listen address) and extip:<IP> (flags.md).

A wrong value must fail at start: $BIN --network apothem --datadir $D --nat bogus exits with status 1, names the accepted values and changes nothing in the datadir. --nat upnp and --nat pmp fail the same way with "not supported yet".

Can I make and probe an enode?

Generate a node key, print its enode, then probe peers. These subcommands are on main only.

$BIN p2p key generate --out $D/nodekey
$BIN p2p key enode --nodekey $D/nodekey --ip 203.0.113.7 --port 30303
$BIN p2p check --network apothem <enode-url> [<enode-url> ...]

Pass for the key: one enode://<128 hex>@203.0.113.7:30303 line, and the same key gives the same line on a second run. Pass for the probe: one line per peer that says ok or the reason (bad enode, unresolved name, port refused, handshake failed, incompatible protocol), and exit 0 when at least one peer is ok. The probe writes nothing.

Does discovery work through a bootnode?

Start a discovery-only bootnode with $BIN p2p bootnode (its flags: $BIN p2p bootnode --help), then start a second follower with --bootnodes <enode> pointing at it. Pass: the follower's admin_peers lists peers found through the bootnode within 5 minutes.

For Apothem the checklist adds a probe of the built-in bootnodes: start the follower as in the first check and count admin_peers after 5 minutes. Pass: 8 or more peers, found from the built-in bootnodes only.

Does the node refuse peers I do not allow?

Write $D/allowed.json, a JSON array of the enode URLs that may connect, and start with --permissions.nodes $D/allowed.json. Pass: a node that is not listed never appears in admin_peers, and the log shows the refusal. If you also name a static or trusted peer that is not in the list, the start must fail: every static and trusted node must be listed.

--netrestrict <CIDR> is the other limit: discovery drops packets from other networks and connections from them are refused (flags.md).

Does it talk to the other XDC clients?

The checklist runs each cell on one host, with the other client on loopback or a private network id. Pass for a cell: the Status handshake completes, then headers, bodies and receipts of blocks 1 to 20 are requested and answered.

REFERENCE TABLEScroll to explore all columns →
Other client How the checklist runs it
geth-XDC, eth/101 XONE_GETH_BIN=<geth-xdc> crates/xone-net/tests/local-geth/run.sh, then the local_geth test of xone-net
legacy XDPoSChain v2.x, eth/100 the same with the legacy binary; admin_peers must show version 100
besu-xdc, xdc-nethermind, xOneGo start the client on a private network id with --netrestrict 127.0.0.0/8, add its enode with --bootnodes, compare eth_getBlockByNumber for blocks 1 to 20

The handshake rules a peer must meet are in spec/net/status62.md.

What does the checklist not cover?

  • The ENR inspect tool and the crawler: not on main.
  • Runtime perm_* RPC methods for the allowlist: not on main.
  • UPnP and NAT-PMP port mapping: refused until the owner decides on a port-mapping dependency.
  • Shutdown with 50 peers (exit within 5 s, p99 over 100 trials), a 1-hour decoder fuzz and a 6-node BFT dedup run: listed as separate jobs.

Record each result in its issue (#32, #167, #178 or #199) with the date, $BIN --version, the host and pass or fail, as the checklist asks.

Frequently asked questions

Can I run these checks with the v0.1.0 release?

Only the first one. The v0.1.0 release has no xone p2p subcommand and no --permissions.nodes flag. Build xone from main for the key, probe, bootnode and allowlist checks.

What does a passing address check look like?

admin_nodeInfo returns an enode with the host's public IP, and the log holds advertised address now <ip> (discovery) after three or more peers agree.

Does xone p2p check change anything?

No. It prints one line per peer, ok or the reason, and writes nothing. It exits 0 when at least one peer is ok.

Can a node outside the allowlist still connect?

No. With --permissions.nodes, any other node is refused in both directions. A static or trusted node that is not listed makes the start fail.

Sources