`nat_open` no longer reports correctly on latest `unstable` (v5.1.0)

[jimmygchen]

Description

The nat_open metric exposed via the /metrics endpoint and the lighthouse/ui/health endpoint doesn't seem to be reporting the status anymore on latest unstable. It seems to be related to the change from #5314.

Version

unstable (v5.1.0 release candidate)

Present Behaviour

• nat_open metric not available on /metrics.
• nat_open always false on lighthouse/ui/health even when the node is reachable from external nodes.

Expected Behaviour

nat_open metric should be available and should return true if node is reachable.

[AgeManning]

I think we now report two kinds. One for tcp and one for udp. So we have to update our metrics and this RPC request I think.

[ackintosh]

Based on my understanding, before #5314, nat_open was determined by check_nat. check_nat would classify it as open (increment NAT_OPEN counter) if either of the conditions below were true.

lighthouse/beacon_node/lighthouse_network/src/metrics.rs

Lines 172 to 173 in 50c423a

	if ADDRESS_UPDATE_COUNT.as_ref().map(|v| v.get()).unwrap_or(0) != 0
	|| NETWORK_INBOUND_PEERS.as_ref().map(|v| v.get()).unwrap_or(0) != 0_i64

Now, nat_open is determined by observe_nat. observe_nat classifies it as open (returns true) only if both of the conditions below are true:

lighthouse/common/system_health/src/lib.rs

Line 217 in a89ff10

discv5_nat && libp2p_nat

So a quick solution that comes to my mind is to update observe_nat to return true if either of the conditions are true like below:

-    discv5_nat && libp2p_nat
+    discv5_nat || libp2p_nat

What do you think? cc @jxs

[jxs]

thanks for noticing and submitting this Jimmy, and Akihito for the fix! Submitted #5427 5427

[ackintosh]

The fix has been released in https://github.com/sigp/lighthouse/releases/tag/v5.1.2 🚀