A repeater already relays every public-channel (GRP_TXT) flood packet that
passes through it. This keeps a bounded, in-RAM ring buffer of those packets so
a client that was out of range can pull back the messages it missed, using an
anonymous request (ANON_REQ sub-type 0x04) -- no login.
Design points:
- Repeater-only. Room server untouched.
- The repeater holds no channel key. Packets are cached and replayed still
channel-encrypted, so a non-member who asks receives ciphertext it cannot
read, and a member decrypts with the key it already has.
- Served directly to the requesting client, never re-flooded, so it adds no
broadcast airtime.
- No login: public channel data is not admin-only. Rate-limited by the existing
anon_limiter, like the other anonymous requests.
- Bounded RAM (32 entries, ~6 KB), nothing persisted -- a rotating cache in the
small internal-flash FS would be a wear anti-pattern.
- Channel broadcasts only, never direct messages, so this does not reintroduce
the ACK/timeout problem that closed#613.
The request params {channel_hash, since_ts, max_count} are optional and
self-describing via a leading length byte, so a stock client that sends only a
reply path gets sensible defaults. A plain length check cannot work here: the
ANON_REQ plaintext is zero-padded to the AES block size, so the decrypted
length exceeds what the sender wrote.
The reply is capped at 160 bytes. reply_data is MAX_PACKET_PAYLOAD (184), but
the binding limit is the companion's host serial frame -- {push code}{reserved}
{tag:4} plus the reply padded to the AES block size minus 4, against
MAX_FRAME_SIZE of 176. Larger replies are transmitted but dropped before the
app sees them. Clients page for the remainder with `since`.
ChannelHistory is a hardware-independent template, covered by 11 googletest
cases under a dedicated native env.
If Bluefruit.begin fails, BLE OTA mode won't actually start and the board might require a reboot to reattempt.
Fixes:
- Bluefruit.begin returns false in NRF52Board.startOTAUpdate if OTA mode fails to start. User is notified of the fault through existing error message in CommonCLI and can reattempt "start ota" command.
mkdocs will only consider the first H1 (if any) and subheaders under it for the table of contents
this increases the header levels of everything below "important concepts" by 1 so that the table of contents correctly resolves them
The room server never supported RX boosted gain, while the repeater
does. Three consequences on SX1262/SX1268 boards:
- boosted gain was never applied to the radio at boot, so a room server
ran in power-saving RX mode while an identical repeater ran boosted -
a real receive-sensitivity difference with nothing pointing at it
- _prefs.rx_boosted_gain was never initialised (the prefs are memset to
0 before defaults are set), so it defaulted to off
- 'set radio.rxgain on' replied "Error: unsupported" but CommonCLI had
already written the value to prefs and saved them, so a stale setting
survived reboot and was never applied
Mirror the repeater's implementation: initialise the pref default under
the same USE_SX1262/USE_SX1268 and SX126X_RX_BOOSTED_GAIN guards, apply
it during radio init, and override setRxBoostedGain() so the CLI reports
success and takes effect.
Built Heltec_v3_room_server (SX1262) and LilyGo_T3S3_sx1276_room_server
(guards compile out cleanly).