Add `filter channel remove <#name|psk|public>` to drop one channel instead
of clearing all. Matched by the resolved key, so any equivalent spec works.
Decode logic shared between add and remove via decodeChannelKey().
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Hashtag channels key off the first 16 bytes of SHA256("#name") (same as
MeshCore clients), so `filter channel #selftest` derives the key directly
instead of needing a pasted PSK.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Keys are never displayed (filter list shows counts only), so persist the
decoded GroupChannel directly instead of the original PSK string. Removes
the 272-byte filter_channel_psk[] buffer and the base64/hex round-trip;
config file is now a versioned binary blob.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
A 16/32-byte key is 32/64 hex chars while base64 PSKs are 24/44 chars, so
all-hex-and-32/64-long disambiguates cleanly. Widen the stored-PSK buffer to
fit a 64-char hex key.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Guard data[len]=0 against an over-long crafted payload (OOB store), and
match keywords against the whole folded message so a blocked word can't be
hidden in the self-declared sender name. Also drop the unguarded ctype.h.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Folds look-alike codepoints (fullwidth, math alphanumerics, circled/
squared letters, regional indicators, Cyrillic/Greek homoglyphs,
accented Latin) to plain ASCII and strips zero-width/combining marks
before matching keywords and sender names.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Adds a MESH_DEBUG line on each dropped message, plus "filter stats"
and "filter stats reset" commands to view/clear the filtered counter.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Lets a repeater decrypt channels it holds the key for (incl. the
built-in public channel) and drop messages matching blocked keywords
or sender names before forwarding. Configured via new "filter" CLI
commands and persisted to /channel_filter.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
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.
* room server: added RegionMap, and new CommonCLI wiring, default_scope handling
* sensor: only minimal RegionMap wiring. Still needs work to handle default-scope
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.
This change counts when readData returns an err code other than RADIOLIB_ERR_NONE. In most cases this is going to be a CRC error. This counter is exposed in the `stats-packets` command, and in the repeater stats payload (4 additional bytes to the payload, which is now 56 bytes with this change. My incompetent robot claims the total payload size is 96 bytes (unverified but probably close).
* ANON_REQ_TYPE_OWNER, firmware-ver removed (security exploit)
* ANON_REQ_TYPE_BASIC, formware-ver removed, just remote clock + some 'feature' bits
* CTL_TYPE_NODE_DISCOVER_REQ now ingored if 'repeat off' has been set