v0.50.0

Nodes upgrade independently, and operators change no configuration. One new line on the air, ping, which older nodes ignore.

What you will notice

Probe always gives an answer (#260, #261). When DAPPS already had a session open with the peer, a probe used to refuse to dial, because a second call resets the link. So it said nothing at exactly the moment you most wanted to know why traffic had stopped. Now it sends a ping down the open session and waits up to a minute for the pong. You get the round trip, or "no answer", along with:

• who called whom, and how long the session has been up
• when the peer was last heard from
• how many of your messages are waiting for an answer, and how long the oldest has waited

That tells apart a link that works, one that is up at your node but gets nothing through (a ping that goes unanswered until the session gives up), and a peer on an older DAPPS that doesn't answer pings.

If DAPPS has the peer marked as in a session but has nothing running to ask, the probe says which way and for how long. After 5 minutes it says it looks stuck; restarting DAPPS clears that.

On the dashboard the answer appears in a pop-up after probe or probe now. Over MCP, run_probe returns it as Detail; POST /Probes/run/{callsign} returns it as detail.

Also

• Pings never count as progress, so probing can't keep open a session whose messages go unanswered. Like any traffic, they do restart an idle session's quiet spell.
• Scheduled probe sweeps take the same path, so a sweep that meets an open session pings it instead of recording a failure.

Known issues

• A peer before 0.50.0 never answers a ping, so a probe of an open session with one reports no answer. The message says so when the peer is still sending.