[Feature Request]: Neighbor broadcasts over LoRa

[azwirko]

Platform

Cross-Platform

Description

This feature request centers around adding support for broadcasting Neighbor info over LoRa using a secondary channel for which a large area Meshtastic network is already in place. We require a means to restore earlier Neighbor functionality where we only need to touch a small subset of nodes sending Neighbor info, without impacting the configuration of hundreds of nodes on our mesh.

Apparently there was a restriction placed on Neighbor broadcasts over LoRa that no longer allows this over a channel with a default name and key, so for example Long Fast and AQ==.

I understand the reasoning for not wanting Neighbor broadcasts on say the Long Fast Slot 0 AQ== that all node firmware seems to come preconfigured with, but here is Northern Virginia we've had an organized Meshtastic mesh growing since July 2023 on Long Fast Slot 9 AQ== where we've implemented Neighbors on select nodes. Its not a private mesh, but by word of mouth or invitation, as we want to educate users on node configurations and try to avoid the mishaps that might negatively impact mesh comms.

We're now trying to contend with what is the best way to regain this Neighbor reporting functionality. We're mainly an RF only Mesh, only lightly relying on our own private MQTT server for the fringe areas until intermediate RF nodes fill in. Many of our relay nodes have no internet to support MQTT, but overall we feel its not a true Mesh when you have to rely on a wired internet backbone.

Is it possible in future firmware releases to restrict the Neighbors over LoRa to the standard default Preset (LongFast), Slot (0/20) AND PSK (AQ==), rather than just Preset and PSK?

Otherwise is there another means to add a feature where we only need touch the select nodes for which Neighbors are configured? Say allow them to push Neighbor traffic over a secondary Channel without us having to touch all 200+ nodes on our mesh?

If no one can suggest another answer to this problem, can a feature of adding a Channel name to the Neighbor Info Config be implemented? This could allow us to easily regain the functionality we've had up until recently. This feature should require only changing/touching relay nodes without having to impact all the other node configurations on our mesh.

Thanks

andyz - K1RA

[garthvh]

If you are using the default slot the channel utilization is not isolated.

[azwirko]

Hi Garth

I understand in general that all Channels ride over the same RF Slot. We are not using the "default" Slot 0/20, but Slot 9 instead. The GitHub commit and comments talk about protecting the public mesh from Neighbor traffic. I'd agree that the only "public" mesh is that LongFast Slot 0/20 PSK="AQ==" mesh. Any and every other Mesh should be considered private and excluded from this new restriction enacted back in November.

Therefore my request is either to restrict the Neighbor over LoRa to the specific "public" LongFast Slot 0 and default PSK, which would seem the easiest to accommodate others that are now in this same unexpected predicament of loosing a key feature

OR

allow us to create a secondary channel, where we must create a new Channel name and PSK, set up Neighbor Conifg to use it and allow us to only share it with those we want as Neighbor reporting over our Mesh. This still allows us to have some level of control and limit RF Slot utilization by this extra traffic. This means we only have to touch a very small subset of nodes on our network.

Again as we have a wide area with numerous nodes, we're looking for any other suggestions to accommodate not having to reconfigure every node on our entire network to maintain functionality we've been relying on for quite some time now.

Thanks for your feedback.

andyz - K1RA

[GUVWAF]

It’s correct that it currently looks for the default name (LongFast) and PSK, so even if you’re using a different frequency slot it won’t allow it.
In my opinion it would be okay to relax the constraint to allow NeighborInfo on non-default frequency slots.

[fifieldt]

Yeah, this does seem like a "well managed" mesh where there's above-average ability to influence good behaviour. Given the high degree of thoughtfulness that's gone into the impact of enabling neighbourinfo on this mesh, and the limited circumstance, I also support relaxing the constraint.