18 KiB
Payload Format
Inside each MeshCore Packet is a payload, identified by the payload type in the packet header. The types of payloads are:
- Node advertisement.
- Acknowledgment.
- Returned path.
- Request (destination/source hashes + MAC).
- Response to REQ or ANON_REQ.
- Plain text message.
- Anonymous request.
- Group text message (unverified).
- Group datagram (unverified).
- Multi-part packet
- Control data packet
- Custom packet (raw bytes, custom encryption).
This document defines the structure of each of these payload types.
NOTE: all 16 and 32-bit integer fields are Little Endian.
Important concepts:
- Node hash: the first byte of the node's public key
Node advertisement
This kind of payload notifies receivers that a node exists, and gives information about the node
| Field | Size (bytes) | Description |
|---|---|---|
| public key | 32 | Ed25519 public key of the node |
| timestamp | 4 | unix timestamp of advertisement |
| signature | 64 | Ed25519 signature of public key, timestamp, and app data |
| appdata | rest of payload | optional, see below |
Appdata
| Field | Size (bytes) | Description |
|---|---|---|
| flags | 1 | specifies which of the fields are present, see below |
| latitude | 4 (optional) | decimal latitude multiplied by 1000000, integer |
| longitude | 4 (optional) | decimal longitude multiplied by 1000000, integer |
| feature 1 | 2 (optional) | reserved for future use |
| feature 2 | 2 (optional) | reserved for future use |
| name | rest of appdata | name of the node |
Appdata Flags
| Value | Name | Description |
|---|---|---|
0x01 |
is chat node | advert is for a chat node |
0x02 |
is repeater | advert is for a repeater |
0x03 |
is room server | advert is for a room server |
0x04 |
is sensor | advert is for a sensor server |
0x10 |
has location | appdata contains lat/long information |
0x20 |
has feature 1 | Reserved for future use. |
0x40 |
has feature 2 | Reserved for future use. |
0x80 |
has name | appdata contains a node name |
Acknowledgement
An acknowledgement that a message was received. Note that for returned path messages, an acknowledgement can be sent in the "extra" payload (see Returned Path) instead of as a separate acknowledgement packet. CLI commands do not cause acknowledgement responses, neither discrete nor extra.
| Field | Size (bytes) | Description |
|---|---|---|
| checksum | 4 | CRC checksum of message timestamp, text, and sender pubkey |
Returned path, request, response, and plain text message
Returned path, request, response, and plain text messages are all formatted in the same way. See the subsection for more details about the ciphertext's associated plaintext representation.
| Field | Size (bytes) | Description |
|---|---|---|
| destination hash | 1 | first byte of destination node public key |
| source hash | 1 | first byte of source node public key |
| cipher MAC | 2 | MAC for encrypted data in next field |
| ciphertext | rest of payload | encrypted message, see subsections below for details |
Returned path
Returned path messages provide a description of the route a packet took from the original author. Receivers will send returned path messages to the author of the original message.
| Field | Size (bytes) | Description |
|---|---|---|
| path length | 1 | length of next field |
| path | see above | a list of node hashes (one byte each) |
| extra type | 1 | extra, bundled payload type, eg., acknowledgement or response. Same values as in Packet Format |
| extra | rest of data | extra, bundled payload content, follows same format as main content defined by this document |
Request
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | sender time (unix timestamp) |
| request data | rest of payload | application-defined request payload body |
For the common chat/server helpers in BaseChatMesh, the current request type values are:
| Value | Name | Description |
|---|---|---|
0x01 |
get stats | get stats of repeater or room server |
0x02 |
keepalive | keep-alive request used for maintained connections |
Get stats
Gets information about the node, possibly including the following:
- Battery level (millivolts)
- Current transmit queue length
- Current free queue length
- Last RSSI value
- Number of received packets
- Number of sent packets
- Total airtime (seconds)
- Total uptime (seconds)
- Number of packets sent as flood
- Number of packets sent directly
- Number of packets received as flood
- Number of packets received directly
- Error flags
- Last SNR value
- Number of direct route duplicates
- Number of flood route duplicates
- Number posted (?)
- Number of post pushes (?)
Get telemetry data
Not defined in BaseChatMesh. Sensor- and application-specific request payloads may be implemented by higher-level firmware.
Get Telemetry
Not defined in BaseChatMesh.
Get Min/Max/Ave (Sensor nodes)
Not defined in BaseChatMesh.
Get Access List
Not defined in BaseChatMesh.
Get Neighbors
Not defined in BaseChatMesh.
Get Owner Info
Not defined in BaseChatMesh.
Response
| Field | Size (bytes) | Description |
|---|---|---|
| content | rest of payload | application-defined response body |
Response contents are opaque application data. There is no single generic response envelope beyond the encrypted payload wrapper shown above.
Plain text message
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | send time (unix timestamp) |
| txt_type + attempt | 1 | upper six bits are txt_type (see below), lower two bits are attempt number (0..3) |
| message | rest of payload | the message content, see next table |
txt_type
| Value | Description | Message content |
|---|---|---|
0x00 |
plain text message | the plain text of the message |
0x01 |
CLI command | the command text of the message |
0x02 |
signed plain text message | first four bytes is sender pubkey prefix, followed by plain text message |
Anonymous request
| Field | Size (bytes) | Description |
|---|---|---|
| destination hash | 1 | first byte of destination node public key |
| public key | 32 | sender's Ed25519 public key |
| cipher MAC | 2 | MAC for encrypted data in next field |
| ciphertext | rest of payload | encrypted message, see below for details |
Room server login
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | sender time (unix timestamp) |
| sync timestamp | 4 | sender's "sync messages SINCE x" timestamp |
| password | rest of message | password for room |
Repeater/Sensor login
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | sender time (unix timestamp) |
| password | rest of message | password for repeater/sensor |
Repeater - Regions request
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x01 (request sub type) |
| reply path len | 1 | path len for reply |
| reply path | (variable) | reply path |
Repeater - Owner info request
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x02 (request sub type) |
| reply path len | 1 | path len for reply |
| reply path | (variable) | reply path |
Repeater - Clock and status request
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x03 (request sub type) |
| reply path len | 1 | path len for reply |
| reply path | (variable) | reply path |
Repeater - Channel history request
Implemented by the repeater firmware. A repeater relays every public-channel
(GRP_TXT) packet that passes through it; with this feature it also keeps a bounded,
in-RAM ring buffer of those packets, so a client that was out of range can pull back
what it missed. It is an anonymous request — no login required — because public
channel data isn't admin-only. The repeater holds no channel key: packets are cached and
replayed still-encrypted, so a non-member who asks just receives ciphertext it can't
read, and a member decrypts with its own channel key. History is served directly to the
requesting client (never re-flooded), so it adds no broadcast airtime.
The request must be sent route-direct (like the other anonymous sub-type requests,
which the repeater gates behind isRouteDirect()), and is rate-limited by the shared
anonymous-request limiter.
| Field | Size (bytes) | Description |
|---|---|---|
| timestamp | 4 | sender time (unix timestamp) |
| req type | 1 | 0x04 (request sub type) |
| reply path len | 1 | path len for reply |
| reply path | (variable) | reply path |
| params len | 1 | optional; 6 if the params below follow, otherwise absent |
| channel hash | 1 | only return this channel's packets; 0xFF = any channel |
| since | 4 | unix timestamp; only packets received strictly after are returned |
| max count | 1 | cap on records in this response; 0 = as many as fit |
Everything from params len onwards is optional: a client that sends only a reply
path (which is all the stock companion's anonymous-request path emits) gets the defaults
channel hash = 0xFF, since = 0, max count = 0 — i.e. recent history for all
channels. The explicit length byte is what makes this safe to detect: the request
plaintext is zero-padded to the AES block size, so a params len read out of that padding
is 0, which is not 6 and therefore reads as "no params".
The response is the reflected 4-byte tag, then a record count, then that many records of
{recv_ts:4}{raw_len:1}{raw:raw_len}, oldest first. Each raw is the original
channel-encrypted GRP_TXT payload exactly as it was relayed, so a channel member decrypts
it with its own key and a non-member cannot read it.
The response is size-capped, so a client must be prepared to page: re-request with since
set to the newest recv_ts received, until a response comes back with a count of zero.
Response (after the standard 4-byte reflected-timestamp tag):
| Field | Size (bytes) | Description |
|---|---|---|
| count | 1 | number of records that follow |
| records | rest | count × record, oldest → newest |
Each record:
| Field | Size (bytes) | Description |
|---|---|---|
| recv ts | 4 | when the repeater received the packet |
| raw len | 1 | length of the raw payload |
| raw | raw len |
the original GRP_TXT payload, verbatim (encrypted) |
A response carries only as many records as fit in one packet. The client pages by
re-requesting with since set to the newest recv ts it received.
Group text message
| Field | Size (bytes) | Description |
|---|---|---|
| channel hash | 1 | first byte of SHA256 of channel's shared key |
| cipher MAC | 2 | MAC for encrypted data in next field |
| ciphertext | rest of payload | encrypted message, see below for details |
The plaintext contained in the ciphertext matches the format described in plain text message. Specifically, it consists of a four byte timestamp, a flags byte, and the message. The flags byte will generally be 0x00 because it is a "plain text message". The message will be of the form <sender name>: <message body> (eg., user123: I'm on my way).
Group datagram
| Field | Size (bytes) | Description |
|---|---|---|
| channel hash | 1 | first byte of SHA256 of channel's shared key |
| cipher MAC | 2 | MAC for encrypted data in next field |
| ciphertext | rest of payload | encrypted data, see below for details |
The data contained in the ciphertext uses the format below:
| Field | Size (bytes) | Description |
|---|---|---|
| data type | 2 | Identifier for type of data. (See number_allocations.md) |
| data len | 1 | byte length of data |
| data | rest of payload | (depends on data type) |
Control data
| Field | Size (bytes) | Description |
|---|---|---|
| flags | 1 | upper 4 bits is sub_type |
| data | rest of payload | typically unencrypted data |
DISCOVER_REQ (sub_type)
| Field | Size (bytes) | Description |
|---|---|---|
| flags | 1 | 0x8 (upper 4 bits), prefix_only (lowest bit) |
| type_filter | 1 | bit for each ADV_TYPE_* |
| tag | 4 | randomly generate by sender |
| since | 4 | (optional) epoch timestamp (0 by default) |
DISCOVER_RESP (sub_type)
| Field | Size (bytes) | Description |
|---|---|---|
| flags | 1 | 0x9 (upper 4 bits), node_type (lower 4) |
| snr | 1 | signed, SNR*4 |
| tag | 4 | reflected back from DISCOVER_REQ |
| pubkey | 8 or 32 | node's ID (or prefix) |
Custom packet
Custom packets have no defined format.