Skip to content

Implement flood.max.unscoped to allow selective repeating of unscoped messages#2661

Merged
ripplebiz merged 2 commits into
meshcore-dev:devfrom
mrzarquon:mrz/flood_max_unscoped
Jun 2, 2026
Merged

Implement flood.max.unscoped to allow selective repeating of unscoped messages#2661
ripplebiz merged 2 commits into
meshcore-dev:devfrom
mrzarquon:mrz/flood_max_unscoped

Conversation

@mrzarquon

Copy link
Copy Markdown
Contributor

As mentioned in #2555 this, having flood.max.unscoped as an alternative to region denyf * would address most peoples primary fear of blocking all unscoped messages - mostly that nearby users new to the mesh won't be able to contact or communicate with anyone until they have the correct regions set.

This fix implements flood.max.unscoped as an additional setting, with the following design considerations:

  • If unset, default value is 0xFF, and the check falls back to the flood.max value (and reports the flood.max.unscoped value as the same as the flood.max value - because it is handled the same way).
  • Once set, packets with ROUTE_TYPE_FLOOD will be checked against this value, while all other packets will be evaluated against the max.flood value. There is currently no way to unset this value, so users will have to change flood.max.unscoped independently of flood.max in the future.

Preliminary testing has been done with repeater firmware, and have verified that both unscoped of <= flood.max.unscoped have passed through, while > flood.max.unscoped were dropped. Scoped messages continued to pass without issue at the same time.

Compiled firmware, based off dev snapshot from the afternoon of 2026-06-01, is available here: https://static.loraproject.org/unscoped/

mrzarquon added 2 commits June 1, 2026 21:30
Before this commit, there was no way to set a different max hop count
for unscoped messages.

Now with this change, by defaul it tracks the flood.max setting, until
a user provides a flood.max.unscoped value, which tax precidence for
packets if ROUTE_TYPE_FLOOD is true.
@ripplebiz

Copy link
Copy Markdown
Member

Thanks for this. Will merge, but will do a few simplifications.

@ripplebiz ripplebiz merged commit 09349c5 into meshcore-dev:dev Jun 2, 2026
12 checks passed
@formtapez

formtapez commented Jun 3, 2026

Copy link
Copy Markdown

It would be good if this feature could be limited to group messages and adverts only.
So pathless DMs can still go through.

That should be easy to implement, like here:
https://github.com/meshcore-dev/MeshCore/pull/1810/changes

@formtapez

formtapez commented Jun 3, 2026

Copy link
Copy Markdown

The danger of the actual implementation of this PR is:
People are turning this on, because it sounds good - But with that, they break DM-functionality on their repeaters.
Direct messages won't find a path to its destination anymore...

@ripplebiz

@mrzarquon

Copy link
Copy Markdown
Contributor Author

@formtapez counter is this is an alternative to people blanket deploying region denyf * so with this change as is, people using devices that haven't set a default region can still send DMs within the radius of the flood.max.unscoped number of hops, which is better than not being able to send any at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants