From 9bb7ccfe53c81dc402d2ed8f2948760bf799bfa1 Mon Sep 17 00:00:00 2001 From: liquidraver <504870+liquidraver@users.noreply.github.com> Date: Tue, 6 Oct 2026 16:59:23 +0200 Subject: [PATCH] upstream dev sync --- docs/CLI_commands.md | 4 ++-- releasenotes/RELEASE_NOTES_1.17.7-zephcore.md | 16 +++++++++++++++- zephcore/app/RepeaterMesh.cpp | 1 + zephcore/app/RepeaterMesh.h | 3 +++ zephcore/boards/common/esp32c3s3_common.conf | 7 ++++--- 5 files changed, 25 insertions(+), 6 deletions(-) diff --git a/docs/CLI_commands.md b/docs/CLI_commands.md index 16e8554..7849899 100644 --- a/docs/CLI_commands.md +++ b/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 ` | 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 ` | 0–64 | Maximum flood retransmit hops | | `set flood.max.unscoped ` | 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 ` | 0–64 | Hop limit for ADVERT floods only (default 8); curbs advert churn independent of flood.max | -| `set flood.advert.interval ` | `0` (off) or 3–168 | How often the repeater floods its own advertisement. `0` disables periodic flood adverts. | +| `set flood.advert.interval ` | `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 ` | `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 ` | | *(room server only)* Allow or deny read-only client connections | | `set guest.password ` | | Set guest access password | diff --git a/releasenotes/RELEASE_NOTES_1.17.7-zephcore.md b/releasenotes/RELEASE_NOTES_1.17.7-zephcore.md index 49a2bf4..f746c5f 100644 --- a/releasenotes/RELEASE_NOTES_1.17.7-zephcore.md +++ b/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. diff --git a/zephcore/app/RepeaterMesh.cpp b/zephcore/app/RepeaterMesh.cpp index 8d3b2c8..59c5830 100644 --- a/zephcore/app/RepeaterMesh.cpp +++ b/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++]; diff --git a/zephcore/app/RepeaterMesh.h b/zephcore/app/RepeaterMesh.h index 744021f..a303af6 100644 --- a/zephcore/app/RepeaterMesh.h +++ b/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 diff --git a/zephcore/boards/common/esp32c3s3_common.conf b/zephcore/boards/common/esp32c3s3_common.conf index a685656..3274b39 100644 --- a/zephcore/boards/common/esp32c3s3_common.conf +++ b/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