upstream dev sync

docs/CLI_commands.md

@@ -76,7 +76,7 @@ Every clock set (these commands, GPS, the app, mesh time sync, SNTP) is also wri
 |---------|-------------|
 | `neighbors` | Display current neighbor list |
 | `neighbor.remove <pubkey_hex>` | Remove a neighbor entry by its public key. A prefix is accepted — the hex is truncated to at most 32 bytes and matched at whatever length you give. **Repeater only in effect:** `RoomServerMesh` does not override `removeNeighbor`, so on a room server this replies `OK` and does nothing. |
-| `discover.neighbors` | *(repeater only)* Broadcast a node discovery request to find nearby nodes; responses are collected for 60 s (as upstream `bf9c6cb5`). Takes no arguments — anything after it replies `Err - discover.neighbors has no options`. Not implemented on room servers. |
+| `discover.neighbors` | *(repeater only)* Broadcast a node discovery request to find nearby nodes; responses are collected for 60 s (as upstream `bf9c6cb5`). Takes no arguments — anything after it replies `Err - discover.neighbors has no options`. A repeater with `repeat off`, or with both advert intervals at `0` (a hidden node, as upstream `f19733e4`), does not answer. Not implemented on room servers. |
 
 ---
 
@@ -433,7 +433,7 @@ four radio parameters together, since they are one interop-critical set.
 | `set flood.max <count>` | 0–64 | Maximum flood retransmit hops |
 | `set flood.max.unscoped <count>` | 0–64 | Hop limit for un-scoped floods only (default 64 = same as flood.max); scoped/transport floods still use flood.max |
 | `set flood.max.advert <count>` | 0–64 | Hop limit for ADVERT floods only (default 8); curbs advert churn independent of flood.max |
-| `set flood.advert.interval <hours>` | `0` (off) or 3–168 | How often the repeater floods its own advertisement. `0` disables periodic flood adverts. |
+| `set flood.advert.interval <hours>` | `0` (off) or 3–168 | How often the repeater floods its own advertisement. `0` disables periodic flood adverts. With `advert.interval` also `0` the repeater is hidden: it stops answering node discovery requests (`discover.neighbors`, the app's discover) as well. |
 | `set advert.interval <mins>` | `0` (off) or min–240 | How often the repeater sends local (zero-hop) advertisements. `0` — the default — disables them. Stored halved (the pref holds minutes/2), so odd values round down. |
 | `set allow.read.only <on\|off>` | | *(room server only)* Allow or deny read-only client connections |
 | `set guest.password <pwd>` | | Set guest access password |

releasenotes/RELEASE_NOTES_1.17.7-zephcore.md

@@ -106,6 +106,13 @@ confirmed yet.
 
 ## Also in this release
 
+- **A repeater with adverts off is no longer discoverable**, as in upstream MeshCore: with both
+  `flood.advert.interval` and `advert.interval` at `0` it stops answering discovery requests (the
+  app's repeater discovery, another repeater's `discover.neighbors`). With either one above `0`, and
+  with the defaults (47 hours and `0`), it answers as before. If a repeater is missing from discovery
+  after the update, check `get flood.advert.interval`: on firmware before 1.17.4,
+  `set flood.advert.interval default` stored `0` by mistake. `set flood.advert.interval default` now
+  puts it back to 47 hours.
 - **Malformed encrypted packets are rejected earlier**, before any cryptography runs.
 - **Large contact lists**: up to 24 contacts can share the same one-byte hash, up from 8.
 - **T1000-E**: a pin that was wrongly driven as a sensor enable is left alone. Sensor readings are
@@ -116,9 +123,16 @@ confirmed yet.
   the command is accepted.
 - **New board**: Seeed LR2021 LoRa Plus EVK with a XIAO nRF54LM20A. Build it from source; there is no
   published firmware for it yet.
-- **Zephyr** updated to `ac03a4a9085`. One change in it would have been visible and is handled:
+- **Zephyr** updated to `74b7173e9c9`. One change in it would have been visible and is handled:
   e-paper displays would have drawn white text on a black page. The RAK4631's LEDs are now declared
   by ZephCore, since Zephyr's board file no longer describes them; nothing changes on the board.
+  It also brings a fix for boards on WiFi: the starting sequence number of a TCP connection (the
+  companion port and the update page) was predictable, and is now derived from a secret as intended.
+- **Heltec V3 and Wireless Tracker companions** (WiFi and Bluetooth together, no PSRAM) had under
+  1 KB of memory left; they now have about 2.5 KB. The Bluetooth controller's stack on ESP32-S3 and
+  ESP32-C3 companions was 4 KB and is now 2 KB: its measured use is 1.1 KB with WiFi connected.
+  Nothing changes in use. Measured on a XIAO ESP32-S3; not run on the two Heltec boards themselves or
+  on an ESP32-C3.
 - **Documentation**: the README was reorganised, build and flashing instructions moved to
   `docs/BUILDING.md`, and the example board and porting guide were rewritten for the current board
   layout.

zephcore/app/RepeaterMesh.cpp

@@ -968,6 +968,7 @@ void RepeaterMesh::onControlDataRecv(mesh::Packet* packet) {
   uint8_t type = packet->payload[0] & 0xF0;    // just test upper 4 bits
   if (type == CTL_TYPE_NODE_DISCOVER_REQ && packet->payload_len >= 6
       && !_prefs.disable_fwd && discover_limiter.allow(rtc_clock.getCurrentTime())
+      && !isHiddenNode()   // this node wishes to NOT be discoverable
   ) {
     int i = 1;
     uint8_t  filter = packet->payload[i++];

zephcore/app/RepeaterMesh.h

@@ -241,6 +241,9 @@ public:
   NodePrefs* getNodePrefs() {
     return &_prefs;
   }
+  bool isHiddenNode() const {
+    return _prefs.advert_interval == 0 && _prefs.flood_advert_interval == 0;
+  }
 
   void savePrefs() override;  // ZEPHCORE: through RepeaterDataStore
 

zephcore/boards/common/esp32c3s3_common.conf

@@ -40,8 +40,9 @@ CONFIG_HEAP_MEM_POOL_SIZE=45056
 # Measured on a XIAO ESP32-S3 companion (2026-10-06, CONFIG_ZEPHCORE_MEM_STATS,
 # devdocs/tools/mem_load.py: fresh pairing, bonded reconnects, protocol golden
 # over BLE, 8 KB sign, 121-contact dump over BLE): peak 980 B at 4096, and
-# 964 B in the same run with the stack at 2048.  2048 is 2.1x the peak and
+# 964 B in the same run with the stack at 2048.  With a Wi-Fi station link up
+# (TCP companion, 8 parallel 1400-byte pings, BLE sessions with contact dumps)
+# the peak is 1108 B, the same on 7 boots out of 7.  2048 is 1.85x that and
 # returns 2 KB of dram0, which the no-PSRAM Wi-Fi + BLE companions (Heltec V3,
-# Wireless Tracker) need.  Not measured with a Wi-Fi station link up
-# (coexistence), and not measured on C3 hardware.
+# Wireless Tracker) need.  Not measured on C3 hardware.
 CONFIG_ESP32_BT_CONTROLLER_STACK_SIZE=2048