CMD_SYNC_NEXT_MESSAGE drains a shared queue, so a host that only advances
its polling loop on packet types it recognizes stalls on the first unknown
one, and everything queued behind it stays undelivered until the next
PACKET_MESSAGES_WAITING. This already bit clients when
PACKET_CHANNEL_DATA_RECV (0x1B) was introduced; spelling it out so the
next added type doesn't repeat it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds RESP_CODE_CONTACT_MSG_SENT_V3 (0x1E) and
RESP_CODE_CHANNEL_MSG_SENT_V3 (0x1F) so firmware that sends messages on
its own (bot auto-replies, on-device keyboard input) can mirror them into
the companion app's history, which today only ever sees inbound traffic
and messages the app itself sent. See #3225.
Both ride the existing offline-queue / MSG_WAITING / SYNC_NEXT_MESSAGE
pipe and reuse the RECV_V3 byte layout, with the pubkey field holding the
recipient instead of the sender and the SNR byte reserved. Requires
app_target_ver >= 3; there is no pre-V3 shape, so older apps are skipped.
Mainline never calls these -- nothing in companion_radio self-originates
messages -- so this is API surface for custom builds, and the linker
drops both functions when unused (identical flash usage before/after).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three factual errors in companion_protocol.md:
- The channel-datagram payload cap was given as 163 (MAX_FRAME_SIZE - 9 when
MAX_FRAME_SIZE was still 172). It went 172 -> 176 in 62f1b11d, but simply
updating the arithmetic to 167 would be worse than the stale value: 167 is
only the host-frame bound (MyMesh.cpp:1265). The radio-side bound is
MAX_GROUP_DATA_LENGTH = 184 - 16 - 3 = 165 (MeshCore.h:21, enforced at
BaseChatMesh.cpp:544). A 166- or 167-byte payload passes the frame check,
fails the radio check, and comes back as ERR_CODE_TABLE_FULL -- which this
same doc describes as "retry later", so a conforming client would retry a
permanently failing send forever. Documents 165 as the limit to enforce and
calls out the 166-167 band explicitly.
- Channel index was documented as 0-7 throughout. The bound is
MAX_GROUP_CHANNELS (BaseChatMesh.cpp:927,936), which is 40 on most current
variants, 8 on some and 1 on others. Clients should read max_channels from
byte 3 of PACKET_DEVICE_INFO instead. Index 0 is pre-populated with the
built-in Public channel but is not reserved.
- The secret field was documented as "all zeros" for public channels. The
firmware always hashes a real 16-byte key; the public channel ships with
izOH6cXN6mrJ5e26oRXNcg== (companion_radio/MyMesh.cpp:111,1040). An all-zero
secret is not a private channel and not an inert one: SHA256 over 16 zero
bytes is a fixed global constant, giving a well-known channel with an
all-zero AES key. searchChannelsByHash skips unnamed slots for exactly this
reason (BaseChatMesh.cpp:392-401), but a named slot with a zero secret is
not skipped and will absorb null-key group traffic from any node. Now
documented as something not to do.
JakubandClaude Opus 5
Robert Ekl
DG1TAL
Liam CottleandGitHub
Sefinek
zjs81
Janez T