meshcore-dev/MeshCore
1
0
Fork 0
mirror of https://github.com/meshcore-dev/MeshCore.git synced 2026-04-20 22:13:47 +00:00
Code Issues Projects Releases Packages Wiki Activity

refactor: extract region.autotag.max.hops cap into a named constant

Browse source 
Replace the magic 8 used in both the load-time sanitize and the CLI
set handler with REGION_AUTOTAG_MAX_HOPS_LIMIT, and surface the cap
in the "Error, range is 0-N" reply so the CLI and the constant can
never drift apart.

Also expand the docs to call out the range explicitly, the clamp-on-
load behaviour, and the rationale for the 8 upper bound (well below
flood.max so auto-tagging can't silently scope distant traffic).
This commit is contained in:
Dale Ruane 2026-04-14 16:56:14 +01:00
parent e5d9eb7c67
commit b2d80391bb
3 changed files with 8 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/cli_commands.md
View file

@ -738,7 +738,9 @@ This document provides an overview of CLI commands that can be sent to MeshCore
- `set region.autotag.max.hops <value>`
**Parameters:**
- `value`: Maximum path hash count (0-8). `0` means only auto-tag packets without scope received directly (zero-hop); higher values also auto-tag packets without scope that already traversed that many repeaters.
- `value`: Maximum path hash count. `0` means only auto-tag packets without scope received directly (zero-hop); higher values also auto-tag packets without scope that already traversed that many repeaters.
**Range:** `0` to `8` (inclusive). Values outside this range are rejected by `set` and clamped to this range on load. The upper bound of `8` is intentionally well below the default `flood.max` of `64`, because auto-tagging packets from far across the mesh almost always produces incorrect region assignments — the limit exists to keep admins honest about the geographic scope they can actually account for.
**Default:** `1`