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
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.
Repeaters with a home region configured now automatically tag untagged
flood packets (ROUTE_TYPE_FLOOD) with the home region's transport code,
converting them to ROUTE_TYPE_TRANSPORT_FLOOD. Also adds TRANSPORT_CODE_ALL
(0xFFFF) as a reserved code that bypasses region filtering, allowing
mesh-wide flooding when explicitly requested.
Instead of overloading getOutboundCount() with a magic sentinel value,
add a dedicated getOutboundTotal() method to the PacketManager interface
that returns the total queue size without time filtering.
This eliminates the fragile convention that caused the regression and
makes the two operations — time-filtered count vs total count —
explicitly separate in the API.
This change addresses two issues. The first is that the
LilyGo_TLora_V2_1_1_6_terminal_chat build would try to compile
simple_repeater/MyMesh.cpp. All other examples of terminal chat
targets are instead building simple_secure_chat/main.cpp . This
change would align this build to the rest of the builds.
The second issue, found during the course of investigating the
first, stems from simple_repeater/MyMesh.cpp using the
MAX_NEIGHBOURS #define to control whether the neighbor list is kept.
Repeaters that keep this list must define this value, and if the
value is not defined, then all neighbor-related functionality is
compiled out. However, the code that replies to
REQ_TYPE_GET_NEIGHBOURS did not properly check for this #define,
and thus any target that compiles simple_repeater/MyMesh.cpp
without defining MAX_NEIGHBOURS would get an undefined variable
compilation error.
As a practical matter though, there are no targets that compile
simple_repeater/MyMesh.cpp AND do not define MAX_NEIGHBOURS,
except this build due to the first issue. As a result, the
second issue is addressed only as a matter of completeness. The
expected behavior with this change is that such a repeater would
send a valid reply indicating zero known neighbors.
