From 2236132df40d6c96da232ed4bb7ee005c967ab5b Mon Sep 17 00:00:00 2001 From: Jack Kingsman Date: Sun, 8 Mar 2026 12:18:57 -0700 Subject: [PATCH] Add note bout brittle meshcore_py on corrupted advert handling --- AGENTS.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 5c8b1a4..710d2d8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -427,3 +427,11 @@ mc.subscribe(EventType.ACK, handler) Byte-perfect channel retries are user-triggered via `POST /api/messages/channel/{message_id}/resend` and are allowed for 30 seconds after the original send. **Transport mutual exclusivity:** Only one of `MESHCORE_SERIAL_PORT`, `MESHCORE_TCP_HOST`, or `MESHCORE_BLE_ADDRESS` may be set. If none are set, serial auto-detection is used. + +## Errata & Known Non-Issues + +### `meshcore_py` advert parsing can crash on malformed/truncated RF log packets + +The vendored MeshCore Python reader's `LOG_DATA` advert path assumes the decoded advert payload always contains at least 101 bytes of advert body and reads the flags byte with `pk_buf.read(1)[0]` without a length guard. If a malformed or truncated RF log frame slips through, `MessageReader.handle_rx()` can fail with `IndexError: index out of range` from `meshcore/reader.py` while parsing payload type `0x04` (advert). + +This does not indicate database corruption or a message-store bug. It is a parser-hardening gap in `meshcore_py`: the reader does not fully mirror firmware-side packet/path validation before attempting advert decode. The practical effect is usually a one-off asyncio task failure for that packet while later packets continue processing normally.