[Protocol delta] PAYLOAD_TYPE_GRP_DATA (channel binary datagrams) not implemented — interop tracking #8

New Issue

2026-10-04T23:05:57+02:00

adam commented

2026-10-04 23:05:57 +02:00

Filing this as a protocol-compatibility tracking item, found while
comparing Meck's mesh-layer implementation against current upstream
meshcore-dev/MeshCore to check interop between this fork (built on
MeshCore v1.11 core) and mainline (currently v1.16) on a shared mesh.

Delta found

BaseChatMesh::onGroupDataRecv() (src/helpers/BaseChatMesh.cpp:355) only
handles PAYLOAD_TYPE_GRP_TXT. There's no branch for
PAYLOAD_TYPE_GRP_DATA (0x06) and no sendGroupData() — this fork can
neither receive nor send channel binary datagrams. Mesh::onRecvPacket()
already decrypts GRP_DATA packets and calls onGroupDataRecv() exactly
like GRP_TXT (src/Mesh.cpp:215-238), so the data does arrive — it's
silently dropped at the application layer with no log.

Why it's worth tracking

GRP_DATA is upstream's registered extension point for apps to broadcast
structured (non-chat) data over a channel, per
docs/number_allocations.md:

0x0100 MeshCore Open (github.com/zjs81/meshcore-open)
0x0110-011F Ripple (the official MeshCore companion app/UI)

Any device sharing a channel with this fork's devices that broadcasts
data via one of those registered apps will have that data silently
ignored on this side — not a crash, just an interop gap.

If/when implemented

Current upstream wire format (as of mainline commit 2f687691, "fix:
Widen grp data type") is:

data_type(2, little-endian) · data_len(1) · payload

(data_type was 1 byte in the original upstream implementation, PR
#1928; it's since been widened to 2 bytes, so any new implementation
here should target the current format to stay compatible with current
mainline-based peers.)

Scope

Regular channel text chat (GRP_TXT) and direct messages are unaffected
by this gap — this is specific to the GRP_DATA extension mechanism.
Not filing as urgent, just tracking the delta for future interop work.

Filing this as a protocol-compatibility tracking item, found while comparing Meck's mesh-layer implementation against current upstream meshcore-dev/MeshCore to check interop between this fork (built on MeshCore v1.11 core) and mainline (currently v1.16) on a shared mesh. ## Delta found `BaseChatMesh::onGroupDataRecv()` (src/helpers/BaseChatMesh.cpp:355) only handles `PAYLOAD_TYPE_GRP_TXT`. There's no branch for `PAYLOAD_TYPE_GRP_DATA` (0x06) and no `sendGroupData()` — this fork can neither receive nor send channel binary datagrams. Mesh::onRecvPacket() already decrypts GRP_DATA packets and calls onGroupDataRecv() exactly like GRP_TXT (src/Mesh.cpp:215-238), so the data does arrive — it's silently dropped at the application layer with no log. ## Why it's worth tracking GRP_DATA is upstream's registered extension point for apps to broadcast structured (non-chat) data over a channel, per docs/number_allocations.md: 0x0100 MeshCore Open (github.com/zjs81/meshcore-open) 0x0110-011F Ripple (the official MeshCore companion app/UI) Any device sharing a channel with this fork's devices that broadcasts data via one of those registered apps will have that data silently ignored on this side — not a crash, just an interop gap. ## If/when implemented Current upstream wire format (as of mainline commit 2f687691, "fix: Widen grp data type") is: data_type(2, little-endian) · data_len(1) · payload (data_type was 1 byte in the original upstream implementation, PR #1928; it's since been widened to 2 bytes, so any new implementation here should target the current format to stay compatible with current mainline-based peers.) ## Scope Regular channel text chat (GRP_TXT) and direct messages are unaffected by this gap — this is specific to the GRP_DATA extension mechanism. Not filing as urgent, just tracking the delta for future interop work.

adam closed this issue

2026-10-27 09:37:23 +01:00

adam commented

2026-10-27 09:37:24 +01:00

Sorry, I'll confess I completely forgot about this. As you can see, it's now been incorporated into a new commit. I need to do quite a bit of testing still, but It'll be in the v1.15 firmware rollout.

Sorry, I'll confess I completely forgot about this. As you can see, it's now been incorporated into a new commit. I need to do quite a bit of testing still, but It'll be in the v1.15 firmware rollout.

adam commented

2026-10-27 09:37:25 +01:00

Closing as it's been added to https://github.com/pelgraine/Meck/releases/tag/v1.15-max with Pro soon to follow.

Closing as it's been added to https://github.com/pelgraine/Meck/releases/tag/v1.15-max with Pro soon to follow.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Meck#8