[Feature Request]: Active node scanning

[Paxy]

Platform

NRF52, ESP32, RP2040, Linux Native, Cross-Platform, other

Description

Have you ever miss the function like active scanning that is available in 802.11 protocol? It would show upon a trigger, what nodes are directly available without waiting for their nodeinfo packet.
One of the solutions for testing direct connectivity is funtion to use metadata request but it requires manual action for each node we exepct be able to hear us.
Active scanning could be implement as following:

• it is triggered on screen menu action "Scan network"
• for each node in nodedb, firmware sends request for metada data (with some specified delay, we should discuss what is acceptable)
  This request for metadata would be idealy set to have zero hop, so not repeatable on any node.

I am aware that function could increase congestion on the network as there would be one message for each node in nodedb for one single action, plus multiple responses for directly connected nodes. Probbably better implementation would be that nodes can broadcast scan request once, and every other node that receives scan request, respond with its metadata packet. Again, scan request should be zero hop.

[fifieldt]

Hi, thanks for the write up. Could you please explain more about when this is valuable/planned to be used?

[MightyBird01]

A function like this would be VERY useful for ad hoc evaluation of a node site. It could also be used to track the conditions in terms of propagation.

[Paxy]

Ok, let me elaborate this idea further. The idea aims to make easier to evaluate location site when setting up the node. Right now, we need to ether leave the node on new location for around 1 hour or request metadata manually for each node to get the data about RSSI and SNR. Active Scanning could, on trigger, speedup that process and enable location survey data (which nodes hear us, and we can hear their response, with both RSSI and SNR data) in the minutes.
The function could be triggered from the menu or apps. The function response is just update of nodedb base with received data.
Technically, the bast implementation path would be to implement probe request packet that can send any node. This packet should have zero hop limitation (not rebroadcastable). It should also be limited to one request in 30-60 seconds. When other nodes receives this packet they respond with their nodeinfo packet in next first available slot (maybe some random delay is needed to avoid congestion).

[overkillthemighty]

I could see the usefulness of this, though I would suggest something more like a 5 min delay.

[nemanjan00]

This feature would not really be destructive for network with a very simple tweak.

Just make hop limit 0 and make sure nobody re-transmits message, since only nodes that are expected to get message and to reply are local nodes anyways.

Also, no need to send message to each node, just make it broadcast. Any node that gets "SCAN_APP" packet, just sends its own nodeinfo, or, at least some kind of ack so signal strength gets updated in nodedb info

So it makes sense to make it more like pinging broadcast IP

Edit:

I see @Paxy already made some of points I did

[MightyBird01]

I think there is a better way to solve this. A CQ function with hop limit 0. All direct nodes hearing the call will respond with RSSI and SNR. This limits the sender TX to 1 and the whole procedure should be done in a few seconds. Another advantage is that you afterwards know who your signal got to. So you have verification that communication works both ways and with which quality. You don't need any information on the sender site for a CQ (like a node list).

[nemanjan00]

I have idea for implementing this so it works with older node versions too...

Just send traceroute...

Nodes get traceroute, add themselves to list and send it on...

If we "hear" packet that has only one node on list, we can assume, it was direct connection and we can hear that node and we also know SNR

It would just need to be able to process packets with the same ID

[MightyBird01]

I think that a CQ feature would also drastically reduce trace route calls.

[nemanjan00]

CQ could be just traceroute with a 1 hop limit (or 2, I am not sure if it would "answer" if it was 1, since it is not technically answer with traceroute, just forwarding modified packet)

[Paxy]

Implementation over trace route using RouteDiscovery packet is not possible as does not return NodeInfo data (node name, RSSI or SNR).
We probably need new protobuf packet encapsulated into MeshPacket to get both scanning request and scanning response with all necessary data.

[pedjas]

This should not be limited to nodes in nodedb, as there may be unknown nodes within range. Scan request should initiate responses from all nodes that hear request directly.