Nodes that open their port with UPnP stay reachable after the first hour
TL;DR: A node that opened its port through UPnP lost its TCP mapping after an hour, and on older routers both mappings lapsed. From v0.0.124 both are renewed every 30 minutes, and the node only advertises an address it has confirmed.
If your node opens its port on your router through UPnP, it could quietly stop being reachable an hour after it started. From v0.0.124, it keeps both of its port mappings alive for as long as it runs, and its log tells you which ones actually worked.
What went wrong
- The TCP mapping lapsed after an hour. It was added once and never renewed, so after the first hour browsers and our gateways’ checks couldn’t reach your node over TCP. The log still said “UDP+TCP”.
- Routers that only speak the older version of UPnP got no renewals at all, so the UDP mapping used for WebRTC lapsed after an hour too.
What is true now
- Both mappings are renewed every 30 minutes, on both router versions.
- A TCP mapping your router refused is tried again at each renewal.
- The startup log says
(UDP+TCP)or(UDP), to match what actually worked. - Your node advertises its UPnP address only while the TCP mapping is confirmed. A setup with only UDP is reported as relayed.
- If your router reports a conflict with a port forward you set up yourself, the warning tells you to set
PUBLIC_ENDPOINTor remove the manual forward.
Why it matters
A node that fails two reachability checks in a row is no longer offered to visitors, unless their browsers can reach it over WebRTC, as described in the entry on how nodes are offered. A lapsed mapping could take your node off that list without any sign in its log.
What you need to do
Update your node to v0.0.124 or later.