Resolves conflict in src/helpers/CommonCLI.cpp where upstream extracted
the get/set handlers into separate methods. Our region.autotag and
region.autotag.max.hops commands are now placed in the new handleGetCmd
and handleSetCmd methods.
* room server: added RegionMap, and new CommonCLI wiring, default_scope handling
* sensor: only minimal RegionMap wiring. Still needs work to handle default-scope
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).
Clarify that with no home region configured, auto-tagging is
effectively disabled regardless of the region.autotag setting,
and untagged floods fall back to the wildcard region's flood
permission.
- Drop VLAN analogy; describe the behaviour directly so the docs
stand on their own.
- Clarify region.autotag.max.hops value description to refer to
"packets without scope" explicitly.
Adds CLI reference entries for the new region.autotag and
region.autotag.max.hops settings, and expands the region home
documentation with guidance on how to choose a home region so
that auto-tagged flood packets are scoped correctly. Also notes
the reserved TRANSPORT_CODE_ALL (0xFFFF) bypass behaviour.
Adds two new repeater prefs to give admins explicit control over
VLAN-style region tagging of untagged flood packets:
region.autotag on|off (default: off)
region.autotag.max.hops 0-8 (default: 1)
Auto-tagging now only occurs when the setting is enabled AND the
received packet's path hash count is <= the configured max hops.
This prevents mis-tagging distant-origin floods that arrived via
untagged / older-firmware repeaters, and ensures home-region
selection is a deliberate admin decision rather than an implicit
side-effect of configuring a home region.
The Waveshare RP2040-LoRa board has an RF switch with two complementary
control lines:
- DIO2 (CTRL) -- driven automatically by the SX1262 chip: HIGH on TX,
LOW on RX
- GPIO17 (!CTRL) -- was not configured in MeshCore, so it floated and
the switch never properly selected the LNA/RX path
Without this pin driven, the RF switch never switches to RX mode,
resulting in completely degraded reception. TX was unaffected because
DIO2 alone is sufficient to activate the TX path.
Adding SX126X_RXEN=17 lets RadioLib drive GPIO17 as the complement of
DIO2, so the switch correctly routes the signal to the LNA on receive.
Reference: https://files.waveshare.com/wiki/RP2040-LoRa/Rp2040-lora-sch.pdf
