[Feature Request]: Native Direct-Link Ping Functionality

[FFAMax]

Platform

Cross-Platform

Description

This request proposes adding a native mechanism for initiating a direct ping to a remote device, either from the device’s local menu or via a CLI command.

The only firmware-side requirement is the ability to recognize a ping request and provide a structured response that includes the SNR and RSSI values measured for the received packet. On the client side, the expected behavior is to display both the remote device’s reported SNR/RSSI and the local device’s SNR/RSSI for the corresponding reply.

This functionality is intended strictly for single-hop, line-of-sight operation. Multi-hop behavior should remain disabled unless explicitly enabled through configuration. The purpose is diagnostic evaluation of direct RF performance, not network-level path testing, unless explicitly configured otherwise.

The request concerns only the base functionality of transmitting a direct ping frame without mesh nodes routing influence. Avoiding mesh routing ensures that measurements are not distorted by intermediate relays. In practice, mesh-assisted delivery can introduce conditions where both a relay node and the line-of-sight node respond concurrently or with differing delays, as commonly observed in traceroute-like scenarios. This feature aims to isolate the physical-layer characteristics between two devices under direct radio visibility.

The proposed feature must operate independently of any NodeDB records. Ping request handling and response generation should not rely on the presence, absence, or state of NodeDB entries. (No ENC)

[statico]

Please, this. +10000

[phaseloop]

Can this be done adapting traceroute with hop limit 1 instead of new feature?

Also I don't know how would you like to ping a host if it's not in NodeDB to choose from? There is also NeighbourInfo - which gathers similar data I think.

[garthvh]

You can easily set the hop limit for your node to 0.

[FFAMax]

The previously provided response suggested configuring the node’s hop limit to zero. This approach does not address the core requirements of the original request. Specifically, it omits the necessity of including RSSI values in the ping response and does not resolve the operational need to issue direct-link diagnostic pings without modifying node settings before each request.

A traceroute-based workaround, where the hop limit is manually adjusted for each transmission, could approximate ping behavior. However, it still fails to meet the essential functional criteria: automatic inclusion of RSSI in the reply and the ability to perform the operation without altering node configuration for every test cycle.

After reviewing the initial response, it is clear that the proposed workaround does not align with the intended scope or goals of the request.

[esev]

FWIW, I've tried this with traceroute and didn't get what I was hoping for. I periodically send 0 hop traceroutes to understand how well my direct neighbors hear me. The send side of this works - my packet is received by the neighbor, but when the neighbor responds there are two downsides:

1. The neighbor doesn't apply a 0 hop count to the response. It instead uses its default hop limit in the reply. So my 0 hop traceroutes end up generating more mesh traffic that I'd hoped for.
2. The neighbor doesn't include RSSI values in the response.

If defined as a direct-link ping (0 rebroadcasts) I think this could add value. A ping to the broadcast address could further optimize specific use-cases, requiring fewer packets to inquire about how all my neighbors are hearing me. It would also allow you to discover your neighbors without waiting to hear a packet from them first.

[FFAMax]

Related feature request #8961 to learn the same info without ping (not instead but to have both).

I've tried demo with beacons instead of manual pings:

DEBUG | 11:06:04 6525 [RadioIf] RSSI -21.00 SNR 8.00
DEBUG | 11:06:04 6525 [RadioIf] Raw incoming packet: 42 43 4e 20 32 31 33 35                          BCN 2135
--
DEBUG | 11:07:44 6625 [RadioIf] RSSI -20.00 SNR 7.75
DEBUG | 11:07:44 6625 [RadioIf] Raw incoming packet: 42 43 4e 20 32 31 33 36                          BCN 2136
--
DEBUG | 11:09:24 6725 [RadioIf] RSSI -20.00 SNR 8.00
DEBUG | 11:09:24 6725 [RadioIf] Raw incoming packet: 42 43 4e 20 32 31 33 37                          BCN 2137
--
DEBUG | 11:11:04 6825 [RadioIf] RSSI -20.00 SNR 7.50
DEBUG | 11:11:04 6825 [RadioIf] Raw incoming packet: 42 43 4e 20 32 31 33 38                          BCN 2138
--
DEBUG | 11:12:44 6925 [RadioIf] RSSI -21.00 SNR 7.25
DEBUG | 11:12:44 6925 [RadioIf] Raw incoming packet: 42 43 4e 20 32 31 33 39                          BCN 2139
--
DEBUG | 11:14:24 7026 [RadioIf] RSSI -20.00 SNR 7.00
DEBUG | 11:14:24 7026 [RadioIf] Raw incoming packet: 42 43 4e 20 32 31 34 30                          BCN 2140
--
DEBUG | 11:16:05 7126 [RadioIf] RSSI -20.00 SNR 7.75
DEBUG | 11:16:05 7126 [RadioIf] Raw incoming packet: 42 43 4e 20 32 31 34 31                          BCN 2141

But need turn it to well-done discovery mechanism combined with extra fields in the nodeDB to avoid probes.
They are short, non-meshastic format so all nodes ignoring them. But the node with the right software can turn this info into topology metrics like OSPF Cost, reduce TX power, etc.

[korbinianbauer]

Ok, so this is 2 independent proposals in one:

1. Including RSSI in the Traceroute. Valid, but have another issue open about this already [Feature Request]: Make traceroute show RSSI along with SNR #8730
2. Possibility to send Traceroutes with hop_start=0 to only probe direct links. As described it's already possible, could just be more convenient

Please don't use LLMs to make your statements much longer than they need to be. I often skip your posts even though I think you have good ideas, just because they're needlessy such a wall of text.

[esev]

This functionality is intended strictly for single-hop, line-of-sight operation. Multi-hop behavior should remain disabled unless explicitly enabled through configuration.

@FFAMax to clarify, are you looking for both the ping request and reply to be single hop (direct - 0 relays)?