-
Notifications
You must be signed in to change notification settings - Fork 964
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Add option to disable automatic nodeinfo requests from node #5238
Comments
After talking to @GUVWAF I think first order of business here is to probably remove the interrogation of unknown nodes from the Router role altogether, since they're not a traditional client. There's some other areas for optimization as well potentially |
Sure, but please also make it an option for normal client role devices. I have some strategically placed nodes that act as routers but have the client role. |
I think we can also disable it when the NodeDB is full. In my opinion it doesn't sound like something that is worth a new setting. |
I would like to keep this open and have a look at disabling the requests when the NodeDB is full. |
See #5255. |
Platform
NRF52, ESP32, RP2040
Description
We have a small problem on our [slovenian] mesh where strategically positioned nodes (routers) have their nodedb filled up pretty fast. This means that nodes are getting removed when the limit (of 100) is reached.
This becomes a real problem when this node hears new packets (position/neighbourinfo/telemetry) from the nodes that it removed and since the node is not present in nodedb, it will sent its nodeinfo to the mesh (also requesting nodeinfo from the unknown node, resulting in two packets being sent over the mesh).
This cycle constantly repeats when you have more than 100 active nodes.
I think the responsible part of the code is in
src/mesh/MeshService.cpp#89
. A new setting would have to be added and an if statement checking that setting when attempting to automatically broadcast node information.This change would only require a protobuf change in a single Config protobuf definition, in my opinion
DeviceConfig
would be a best fit.The text was updated successfully, but these errors were encountered: