deploy: 5b0af29ad1

cli_commands/index.html

@@ -5690,13 +5690,18 @@ reduce false recoveries when no traffic is expected.</p>
 <p><strong>Default:</strong> <code>flood.channel.data on</code>; <code>flood.channel.data.hops h=all</code></p>
 <p><strong>Forwarding behavior:</strong> Repeater firmware only. The repeater still receives and
 logs the packet when logging is enabled; this only blocks retransmission.
-This is checked before FPF7 and applies to flood <code>GRP_DATA</code> packets regardless
-of channel key. Flood group text (<code>GRP_TXT</code>) is unaffected by this setting.</p>
+On generalized repeaters these commands manage an ordinary visible FPF7
+<code>type=grp_data</code> drop row. <code>off</code> with <code>all</code> maps to <code>hops=all</code>; <code>off</code> with <code>N</code>
+maps to <code>hops=N+1+</code>. The 240 KB compact FPF6 profiles retain the legacy hard
+gate. Because it is an ordinary FPF7 row, a matching higher-priority <code>stop</code>
+rule can exempt traffic from it. The compact <code>get flood.filter</code> list marks the
+managed row with <code>~data</code>. Flood group text (<code>GRP_TXT</code>) is unaffected by this
+setting.</p>
 <p><code>get flood.channel.data</code> includes the active hop gate as <code>h=all</code> or <code>h&gt;N</code>.</p>
 <hr />
 <h4 id="block-selected-flood-channels-with-fpf7">Block selected flood channels with FPF7</h4>
 <p>The separate <code>flood.channel.block</code> command and 15-row table have been retired.
-Generalized repeaters use the 31-row FPF7 table for authenticated channel
+Generalized repeaters use the 32-row FPF7 forward phase for authenticated channel
 blocks:</p>
 <pre><code class="language-text">set flood.rule type=any channel=#test hops=all drop
 set flood.rule.2 type=any channel=#wardriving hops=5+ drop
@@ -5959,8 +5964,8 @@ for remote changes. It does not have the repeater's passive path blacklist, so
 ordered <code>prefix=</code> match on a room server. Standard room-server profiles do not
 compile this table.</p>
 <p><strong>Parameters:</strong>
-- <code>n</code>: Rule slot in the build's compiled table (normally <code>1-31</code>; some
-  constrained profiles use fewer slots).
+- <code>n</code>: Forward-rule slot in the build's compiled table (<code>1-32</code> on generalized
+  repeaters and <code>1-31</code> on FULL room servers; compact profiles may use fewer).
 - <code>type</code>: Payload type name, full <code>PAYLOAD_TYPE_*</code> name, decimal value <code>0-15</code>,
   hexadecimal value <code>0x00-0x0F</code>, or <code>any</code>.
 - <code>hops</code>: Optional; omitted means <code>all</code>.
@@ -6123,7 +6128,7 @@ against the same immutable receive-time packet, before any rule changes its
 scope. Matching rows are processed in descending <code>priority</code>, with lower slot
 number winning a tie. The first matching <code>stop</code> row is included and all
 lower-order FPF7 matches are discarded. A stop cannot undo an earlier drop or
-bypass hard forwarding gates and separate forwarding tables. A row with
+bypass hard forwarding gates or the other policy phases. A row with
 <code>path=blacklist</code> must meet the path condition as well as its other conditions;
 blacklist IDs can occur anywhere in the received path and their configured
 order is irrelevant. In contrast, <code>prefix=</code> begins at the first received path
@@ -6195,11 +6200,18 @@ means <code>prefix=</code>, <code>i=*|n|s|a|u|s:&lt;scope&gt;|r:&lt;region&gt;</
 combines slow timing
 (<code>s</code>) with temporary-radio suspension (<code>t</code>). Packet type is shown numerically
 in that fallback. Normal-sized rows keep the descriptive spelling above.</p>
-<p>The blacklist and filter rows are persisted separately. Replacing or deleting
+<p>On generalized repeaters, filter rows, scope-rewrite rows, the shared
+blacklist, and <code>flood.channel.data</code> compatibility state are committed in one
+atomic FPF7 image. Compact FPF6 profiles retain separate files. Replacing or deleting
 the blacklist does not delete rows containing <code>path=blacklist</code>; such rows
 remain dormant while the list is empty. Path hashes are truncated routing
 identifiers, not authenticated identities, so this is a forwarding signal
 rather than proof that a particular repeater handled a packet.</p>
+<p>A common use is containment of bulk internet-to-mesh dumping: list the path
+IDs associated with the offending gateways, then add a broad
+<code>type=any hops=all path=blacklist drop</code> row. This prevents this repeater from
+retransmitting matching floods; it does not delete them from local logs or
+prove who originated them.</p>
 <p>The unnumbered blacklist <code>set</code> replaces the whole list and accepts up to 18 IDs
 so it fits every CLI transport. Numbered <code>set</code> writes up to 18 consecutive
 entries beginning at an existing slot or exactly the next slot, allowing an
@@ -6240,7 +6252,7 @@ and adds <code>#BlackHole86</code> only when no scope was present. The second re
 exact incoming <code>#usa</code> scope. The third demonstrates a two-byte pbyte source
 prefix and a global per-row rate cap. The fourth authenticates <code>#rgdata</code> at
 zero through two hops, applies no FPF7 action of its own, and stops lower-order
-FPF7 rows; hard gates and separate tables still apply.</p>
+FPF7 forward rows; hard gates and the rewrite/moderation phases still apply.</p>
 <p>The fixed 240 KB STM32WL profiles leave
 <code>MESH_ENABLE_FLOOD_RULE_ENGINE=0</code> and retain the compact, persistent FPF6
 <code>flood.filter</code> and blacklist commands. They still filter floods, but do not

filter_tool/index.html

@@ -525,6 +525,17 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#current-fpf7-command-mapping" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Current FPF7 command mapping
+      
+    </span>
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1024,6 +1035,17 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#current-fpf7-command-mapping" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Current FPF7 command mapping
+      
+    </span>
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1069,12 +1091,13 @@ such as dropping, scoping, rate-limiting, or retrying a flood.</p>
 <p>Everything runs locally in this browser. Channel keys, packet facts, and policy
 drafts are not uploaded anywhere.</p>
 <div class="filter-design-warning" role="note">
-  <strong>Engine design preview</strong>
+  <strong>Policy design preview</strong>
   <p>
-    This page targets the new policy-engine idea, not today's FPF7 file or
-    existing <code>set flood.*</code> commands. Its readable policy language,
-    JSON, and Base64 bundle are a prototype for design testing. Current
-    firmware cannot install these policies yet.
+    The phases and core conditions model current FPF7 behavior, including its
+    forward rows, scope rewrites, and shared blacklist. The readable policy
+    language, JSON, and Base64 bundle are still a prototype: current firmware
+    is configured with <code>set flood.*</code> commands and cannot install a
+    bundle from this page.
   </p>
 </div>
 
@@ -1165,7 +1188,7 @@ in the simulator below. The examples draw from
         <code>when type=grp_txt hops=all channel=public sender="Noisy User" do rate=5/min burst=5</code>
       </button>
       <button type="button" data-example="blacklist">
-        <span>Drop packets whose path matches the passive blacklist</span>
+        <span>Stop forwarding traffic from blacklisted internet gateways</span>
         <code>when type=any hops=all path=blacklist do drop</code>
       </button>
       <button type="button" data-example="factory">
@@ -1732,6 +1755,37 @@ The class column shows which broader selector also matches it.</p>
 </tr>
 </tbody>
 </table>
+<h2 id="current-fpf7-command-mapping">Current FPF7 command mapping</h2>
+<table>
+<thead>
+<tr>
+<th>Firmware command</th>
+<th>FPF7 role</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>flood.rule</code> / <code>flood.filter</code></td>
+<td>Forward-phase match and action rows</td>
+</tr>
+<tr>
+<td><code>flood.channel.data</code></td>
+<td>Compatibility view over one visible <code>type=grp_data</code> forward drop row</td>
+</tr>
+<tr>
+<td><code>flood.channel.scope</code></td>
+<td>Scope-rewrite phase rows</td>
+</tr>
+<tr>
+<td><code>flood.filter.blacklist</code></td>
+<td>One shared unordered path-ID set referenced by <code>path=blacklist</code> rows</td>
+</tr>
+</tbody>
+</table>
+<p>Generalized repeaters commit those sections together. The blacklist is useful
+for refusing to retransmit floods associated with internet gateways dumping
+bulk traffic, but a path ID is truncated and unauthenticated; it identifies a
+routing pattern, not a person.</p>
 <h2 id="proposed-evaluation-contract">Proposed evaluation contract</h2>
 <p>The simulator uses these rules:</p>
 <ol>

flood_filtering/index.html

@@ -1366,8 +1366,8 @@
 <p>This guide explains the Keymind forwarding filters. Repeaters expose the full
 set of channel, rule, blacklist, and moderation controls described here.
 FULL-profile ESP32 room servers expose the generalized <code>flood.rule</code> table (and
-its <code>flood.filter</code> alias) with 31 slots, but not the repeater's channel tables,
-passive blacklist, or text-moderation table. Standard room-server profiles do
+its <code>flood.filter</code> alias) with 31 forward-rule slots, but not the repeater's
+scope-rewrite, passive-blacklist, or text-moderation phases. Standard room-server profiles do
 not compile the rule table. Filters decide whether the node retransmits a
 packet and can assign a transport scope before that decision. They do not stop
 local reception, packet logging, or MQTT observation.</p>
@@ -1393,11 +1393,14 @@ get flood.channel.scope
 get flood.channel.scope.require
 get flood.filter
 get flood.rule
+get flood.filter.blacklist
 get flood.moderation
 </code></pre>
-<p><code>flood.rule</code> is an alias for <code>flood.filter</code>, not another table. The
-The generalized FPF7 table has 31 persistent slots; compact target profiles
-may compile fewer FPF6 filter slots. <code>flood.moderation</code> has 16 slots. A new
+<p><code>flood.rule</code> is an alias for <code>flood.filter</code>, not another table. Generalized
+repeater FPF7 has 32 forward-rule slots plus scope-rewrite and shared-blacklist
+sections in the same atomic policy file. FULL room servers have 31 forward
+slots and empty repeater-only sections. Compact target profiles retain their
+separate FPF6-era controls. <code>flood.moderation</code> has 16 slots. A new
 repeater FPF7 table starts with <code>ota all suspend=tempradio</code> in slot 1 and an
 authenticated <code>#wardriving hops=5+</code> drop in slot 2; FULL room servers seed only
 the OTA row. <code>flood.moderation</code> starts empty. A row can opt into
@@ -1513,15 +1516,14 @@ actually active temporary-radio window, even if the seeded row is deleted or
 replaced.</p>
 <p>Capacity is selected at build time:</p>
 <ul>
-<li>Roomy ESP32 builds: 255 rule slots and 32 regionless-target slots, 10,204
-  bytes RAM, 10,210-byte file.</li>
+<li>Roomy ESP32 builds: 255 rewrite slots and 32 regionless-target slots, 10,204
+  bytes RAM.</li>
 <li>DRAM-tight classic ESP32 LoRa-OTA repeaters, nRF52, and other normal
-  constrained builds: 31 rule and regionless-target slots, 2,108 bytes RAM,
-  2,114-byte file.</li>
-<li>Very-tight STM32WL builds: 15 rule slots and one reusable regionless-target
-  slot, 572 bytes RAM, 578-byte file.</li>
-<li>The no-PSRAM LilyGo T-LoRa V2.1 repeater/observer: 4 rule and
-  regionless-target slots, 272 bytes RAM, 278-byte file. This minimum holds the
+  constrained builds: 31 rewrite and regionless-target slots, 2,108 bytes RAM.</li>
+<li>Very-tight STM32WL builds: 15 rewrite slots and one reusable regionless-target
+  slot, 572 bytes RAM.</li>
+<li>The no-PSRAM LilyGo T-LoRa V2.1 repeater/observer: 4 rewrite and
+  regionless-target slots, 272 bytes RAM. This minimum holds the
   three wildcard classes and one exact channel mapping.</li>
 </ul>
 <p>Each rule retains its 36-byte record. A separate table holds 32-byte normalized
@@ -1529,6 +1531,9 @@ names for up to the smaller of the rule count or 32 distinct regionless
 targets, except that very-tight STM32WL builds retain one reusable direct
 target. Both configured regions and regionless targets can be reused by any
 number of rules.</p>
+<p>On generalized builds these records are the FPF7 rewrite phase, and the file
+stores only through the highest occupied slot. Compact FPF6 builds retain the
+standalone FCS5 file and the file sizes described by their build profile.</p>
 <h2 id="require-valid-incoming-scopes-only-on-selected-channels">Require valid incoming scopes only on selected channels</h2>
 <p><code>flood.channel.scope.require</code> changes region enforcement for received flood
 <code>GRP_TXT</code> and <code>GRP_DATA</code> packets from a global policy to a channel opt-in
@@ -1602,9 +1607,17 @@ open. A row saved by the extended engine uses FPF7.</p>
 <p>The former <code>flood.channel.block</code> table is now represented by ordinary FPF7
 rows. On a generalized repeater, an existing FCB2 file is imported once into
 free FPF7 slots and then removed. For example, an old <code>#wardriving h=4</code> row
-becomes <code>type=any channel=#wardriving hops=5+ drop</code>. The 31 FPF7 slots replace
-the former 16 general-filter plus 15 channel-block slots. Compact STM32WL FPF6
-builds cannot match authenticated channels.</p>
+becomes <code>type=any channel=#wardriving hops=5+ drop</code>. The 32nd forward slot
+guarantees room to migrate the old global <code>flood.channel.data</code> gate even when
+all 31 former general/channel slots were occupied. Compact STM32WL FPF6 builds
+cannot match authenticated channels and retain the older separate gate.</p>
+<p>On generalized repeaters, <code>flood.channel.data*</code> is a compatibility view over
+one ordinary visible FPF7 <code>type=grp_data ... drop</code> row. Turning it off creates
+or updates that row; turning it on removes the row. Its hop setting maps to
+<code>hops=all</code> or <code>hops=N+1+</code>. There is no hidden GRP_DATA forwarding check ahead
+of FPF7. Normal ordering applies, so a matching higher-priority <code>stop</code> row can
+exempt selected traffic. The compact rule list marks the managed row with
+<code>~data</code>.</p>
 <p>FPF7 binds <code>in=region:&lt;name&gt;</code> and <code>region=&lt;name&gt;</code> to canonical region names,
 not numeric region IDs. Removing, reordering, or reusing a region ID cannot
 silently redirect a rule. If the saved name is missing, an input-region match
@@ -1624,11 +1637,11 @@ Every row is matched against the same immutable packet state captured on
 receive, before any rule rewrites its scope. Matching rows are then processed
 by descending <code>priority</code>; lower slot number wins a priority tie. Priority
 defaults to <code>0</code>.</p>
-<p>The first matching <code>stop</code> row ends FPF7 processing after that row. Higher-order
+<p>The first matching <code>stop</code> row ends the FPF7 forward phase after that row. Higher-order
 matches and the stop row still apply; lower-order matches do not. A stop-only
 row is therefore an exception to lower-priority FPF7 rows. It cannot undo a
-higher-priority drop and it does not bypass hard forwarding gates or separate
-forwarding tables. Without a stop row, matching drop and rate rows remain
+higher-priority drop and it does not bypass hard forwarding gates or the
+scope-rewrite and moderation phases. Without a stop row, matching drop and rate rows remain
 independent and the highest-order matching scope or region rewrite wins.</p>
 <p>Match fields:</p>
 <ul>
@@ -1725,6 +1738,10 @@ del flood.filter all
 set flood.filter.blacklist.4 445566
 set flood.filter any all path=blacklist
 </code></pre>
+<p>This is intended for abuse containment, such as refusing to retransmit floods
+that repeatedly enter the mesh through known internet gateways dumping bulk
+traffic. The list is shared by every FPF7 row and scope-rewrite row that uses
+<code>path=blacklist</code>; it is not copied into each rule.</p>
 <p>An unnumbered <code>set</code> replaces the list with up to 18 IDs, the largest command
 that fits every CLI transport. A numbered <code>set</code> writes a batch of up to 18 IDs
 beginning at an existing slot or the next consecutive slot. This is how an
@@ -1773,13 +1790,15 @@ maximum <code>txdelay</code> factor of <code>2.0</code>; the randomized transmit
 zero through ten packet airtimes. <code>tx=fast</code> explicitly restores the default.
 Selecting the scope already present does not grant special treatment. Active
 radio transmission, CAD, and airtime-budget limits are unchanged.</p>
-<p>On repeaters, the blacklist and rule table are persisted separately. FPF7
-stores compiled match/action fields and canonical region names, not executable
-code, a script, or numeric region references. Deleting the blacklist leaves
-<code>path=blacklist</code> rows in place but dormant until IDs are configured again.
-Path hashes are truncated routing identifiers and are not authenticated proof
-that a particular repeater handled a packet. FULL room servers have only the
-rule table and reject blacklist commands.</p>
+<p>On generalized repeaters, forward rules, <code>flood.channel.scope</code> rewrite rows,
+the shared blacklist, and the <code>flood.channel.data</code> compatibility state are one
+atomic FPF7 policy image. Existing <code>/flood_ch_scope</code>, <code>/flood_filter_bl</code>, FPF6,
+and FCB2 data is imported once; the old files are removed only after the new
+image verifies and commits. Compact FPF6 repeaters retain separate files.
+Deleting the blacklist leaves <code>path=blacklist</code> rows in place but dormant until
+IDs are configured again. Path hashes are truncated routing identifiers and
+are not authenticated proof that a particular repeater—or a particular
+person—handled a packet. FULL room servers reject blacklist commands.</p>
 <p>On first initialization, flood-filter slot 1 is seeded with:</p>
 <pre><code class="language-text">set flood.filter.1 0x0C all suspend=tempradio
 </code></pre>
@@ -2065,8 +2084,9 @@ other words, the controls combine as deny rules:</p>
    then ascending slot. The first matching <code>stop</code> row removes every later FPF7
    match. The highest-order remaining <code>scope=</code> or <code>region=</code> row may replace the
    channel-scope result; a direct scope does not require a region-list entry.</li>
-<li><code>repeat</code>, <code>flood.max*</code>, and the channel-data gate are checked.</li>
-<li>Remaining <code>flood.filter</code>/<code>flood.rule</code> drop and rate rows use that saved
+<li><code>repeat</code> and <code>flood.max*</code> are checked.</li>
+<li>The FPF7 forward phase, including any row managed through
+   <code>flood.channel.data*</code>, applies drop and rate decisions using that saved
    match result. No packet type or short-hop range is silently exempted.</li>
 <li>Region and loop-detection rules are checked; a regionless scope assigned by
    either table is already trusted when it has no region-list match, except

halo_keymind_settings/index.html

@@ -1329,19 +1329,19 @@ set flood.retry.ignore none
 </tr>
 <tr>
 <td><code>flood.channel.data</code></td>
-<td>Turns forwarding of all flood <code>GRP_DATA</code> channel packets on or off. The default is <code>on</code>; use an authenticated FPF7 <code>channel=</code> drop when only selected channels should be blocked.</td>
+<td>Compatibility view for a visible FPF7 <code>type=grp_data</code> drop row on generalized repeaters. <code>off</code> creates the row and <code>on</code> removes it; compact FPF6 builds retain the legacy gate. Use an authenticated <code>channel=</code> row when only selected channels should be blocked.</td>
 <td><code>get flood.channel.data</code>, <code>set flood.channel.data on/off</code></td>
 <td><code>set flood.channel.data off</code></td>
 </tr>
 <tr>
 <td><code>flood.channel.data.hops</code></td>
-<td>Separate hop gate used only when <code>flood.channel.data</code> is <code>off</code>; <code>all</code> blocks <code>GRP_DATA</code> at any hop count, <code>1</code>-<code>7</code> repeats at that hop count or lower and blocks longer paths.</td>
+<td>Sets the compatibility row's hop range: <code>all</code> maps to <code>hops=all</code>; <code>1</code>-<code>7</code> repeats through that hop count and maps to <code>hops=N+1+</code>.</td>
 <td><code>get flood.channel.data.hops</code>, <code>set flood.channel.data.hops &lt;all|1-7&gt;</code></td>
 <td><code>set flood.channel.data.hops 7</code></td>
 </tr>
 <tr>
 <td><code>flood.channel.scope</code></td>
-<td>Adds a transport scope to received unscoped floods or replaces the scope of already-scoped floods. A bare target uses an existing flood-allowed region; <code>scope=&lt;name&gt;</code> derives a public hashtag target directly without creating a region, exactly like <code>flood.filter scope=</code>. By default, a changed packet bypasses inbound <code>rxdelay</code> and is forwarded at the highest outbound queue priority with zero initial <code>txdelay</code>, so the selected scope can win at the next hop. <code>tx=slow</code> uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retains normal queue priority, and forces the maximum <code>txdelay</code> factor of <code>2.0</code>; its actual randomized transmit delay ranges from zero through ten packet airtimes. <code>path=blacklist</code> and <code>path=bucket:&lt;1-6&gt;</code> make a row path-qualified; bridge buckets remain usable while bridge retry is off. An already-matching scope is a no-op. Exact channel keys beat <code>txt:*</code>; path-qualified rows beat the ordinary channel fallback. <code>login:*</code> covers the remote-login family, and <code>other:*</code> covers every remaining flood type, including flood-form TRACE and OTA. Direct traceroute remains outside the flood table. ACL permission <code>4</code> can manage the table.</td>
+<td>FPF7 rewrite-phase rows that add a transport scope to received unscoped floods or replace the scope of already-scoped floods. A bare target uses an existing flood-allowed region; <code>scope=&lt;name&gt;</code> derives a public hashtag target directly without creating a region, exactly like <code>flood.filter scope=</code>. By default, a changed packet bypasses inbound <code>rxdelay</code> and is forwarded at the highest outbound queue priority with zero initial <code>txdelay</code>, so the selected scope can win at the next hop. <code>tx=slow</code> uses an effective inbound <code>rxdelay</code> base of <code>max(2, configured rxdelay * 2)</code>, retains normal queue priority, and forces the maximum <code>txdelay</code> factor of <code>2.0</code>; its actual randomized transmit delay ranges from zero through ten packet airtimes. <code>path=blacklist</code> and <code>path=bucket:&lt;1-6&gt;</code> make a row path-qualified; bridge buckets remain usable while bridge retry is off. An already-matching scope is a no-op. Exact channel keys beat <code>txt:*</code>; path-qualified rows beat the ordinary channel fallback. <code>login:*</code> covers the remote-login family, and <code>other:*</code> covers every remaining flood type, including flood-form TRACE and OTA. Direct traceroute remains outside the flood table. Generalized builds commit these rows with the forward phase and blacklist; compact FPF6 builds retain separate storage. ACL permission <code>4</code> can manage the table.</td>
 <td><code>get flood.channel.scope[.n]</code>, <code>set flood.channel.scope[.n] &lt;channel|txt:*|login:*|other:*&gt; &lt;region|scope=name&gt; [path=blacklist|path=bucket:1-6] [tx=slow]</code>, <code>del flood.channel.scope.&lt;n&gt;|all</code></td>
 <td><code>set flood.channel.scope #rgdata scope=BlackHole86</code></td>
 </tr>
@@ -1353,7 +1353,7 @@ set flood.retry.ignore none
 </tr>
 <tr>
 <td><code>flood.filter</code></td>
-<td>Persistent flood-route rules selected by payload type and optional hop range. Extended builds have 31 FPF7 slots and add authenticated channel, ordered pbyte prefix, original scope/region, rewrite, rate, priority, and terminal stop fields; <code>flood.rule</code> is an alias for the same table. Repeaters also support a separate unordered <code>path=blacklist</code>. FULL ESP32 room servers have the same 31 extended slots but no blacklist and require remote administrator access. Fixed 240 KB STM32WL repeaters retain compact FPF6 filtering and blacklist commands. New generalized repeater tables seed slot 1 with <code>ota all suspend=tempradio</code> and slot 2 with an authenticated <code>#wardriving hops=5+</code> drop. Direct routes and local receive/logging are unchanged.</td>
+<td>Persistent flood-route rules selected by payload type and optional hop range. Generalized repeaters have 32 FPF7 forward slots; FULL ESP32 room servers have 31. Repeaters store their scope-rewrite phase, shared unordered blacklist, and channel-data compatibility state in the same atomic FPF7 image. <code>path=blacklist</code> is intended for forwarding abuse containment, including bulk internet-to-mesh dumping, but truncated path IDs are not authenticated identities. Fixed 240 KB STM32WL repeaters retain compact FPF6 filtering and separate blacklist storage. New generalized repeater tables seed slot 1 with <code>ota all suspend=tempradio</code> and slot 2 with an authenticated <code>#wardriving hops=5+</code> drop. Direct routes and local receive/logging are unchanged.</td>
 <td><code>get flood.filter[.n]</code>, <code>set flood.filter[.n] &lt;type&gt; [N|N+|N-M|all] [scope=&lt;name&gt;] [require=region] [tx=slow] [suspend=tempradio]</code>, <code>del flood.filter.&lt;n&gt;|all</code>; repeater only: <code>get/set/del flood.filter.blacklist[.n]</code></td>
 <td><code>set flood.filter grp_txt all scope=local tx=slow</code></td>
 </tr>

sitemap.xml

@@ -2,102 +2,102 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
     <url>
          <loc>https://mikecarper.github.io/MeshCore/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/WiFi/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/cli_build_matrix/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/cli_command_availability/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/cli_commands/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/companion_protocol/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/docs/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/faq/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/filter_tool/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/flood_filtering/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/gps_tracking/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/halo_keymind_settings/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/kiss_modem_protocol/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/nrf52_power_management/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/number_allocations/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_easy/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_meshtower_v2_sdcard/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_protocol/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_user_guide/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/packet_format/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/payloads/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/qr_codes/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/stats_binary_frames/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/telemetry_decoder/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/terminal_chat_cli/</loc>
-         <lastmod>2026-08-07</lastmod>
+         <lastmod>2026-08-08</lastmod>
     </url>
 </urlset>