Additional projects
µMesh
Nodes need a small mesh-style protocol over a raw 802.11 frame abstraction.
C99 PHY, MAC, network and optional power modules provide discovery, routing and retry behavior.
Stablev1.5.0MITC99
01 / NETWORK SHAPE
Mesh roles and addresses over raw-frame PHY
µMesh is a C99 library that places PHY abstraction, MAC behavior and network discovery/routing over a raw 802.11 frame interface. Addresses are an 8-bit network ID and 8-bit node ID; broadcast is 0x00, coordinator 0x01, and unassigned 0xFE.
coordinator↔router↔end node·auto role
The implementation has bounded node, route and neighbor capacities that depend on UMESH_RAM_KB. The public header currently sets maximum payload to 64 bytes and maximum hop count to 15. These constants describe implementation bounds; they do not establish practical RF capacity or range.
02 / PACKET LIFECYCLEPHYRaw frame interfaceESP32 and POSIX ports documented →MACSense, back off, ACKpriority and retry logic →NETWORKAddress and routediscovery and multi-hop forwarding →APPLICATIONReceive command/payloadAPI-driven handling
Separate frame handling, medium access and network forwarding
The repository distinguishes the package version from UMESH_WIRE_VERSION. A release tag is not a wire-compatibility guarantee, and a wire-version value is not a package release number.
03 / DISCOVERY AND ROUTINGDEFAULT MANY-TO-ONE LIFECYCLE
Two routing modes with different state costs
Distance vector
Maintains route-table entries by destination and is documented for smaller networks and bidirectional traffic. Measured network-size scalability is not claimed.
Gradient to coordinator
Nodes track hop distance to coordinator. A beacon that improves local distance is rebroadcast with configured random jitter, capped by maximum hop count. Forwarding chooses a neighbor with a lower distance, preferring the smallest distance and then stronger RSSI on ties.
Join and membership
Protocol commands cover join, assign, leave, discover, route updates, node events and election. Timers and node timeouts are compile-time constants documented in the public headers.
Scalability boundary. The repository marks node-count scalability and gradient density claims as unmeasured. No RF range or supported network-size benchmark is published.
04 / MEDIUM ACCESS
CSMA/CA, acknowledgement and retry policy
The MAC path includes channel-sense status, binary exponential backoff, acknowledgement handling, bounded retransmission and packet priority. The header defines a one-millisecond slot, two-millisecond CCA window, 50-millisecond ACK timeout, four maximum retries and an RSSI threshold constant.
The MAC documentation explicitly labels the rationale behind its 50 ms timeout as an estimate, not measured timing evidence. Physical radio latency, collision rate, throughput and current draw are not established by these constants.
SEND STATE
listen for channel
↓ busyrandomized backoff
↘ free channeltransmit and await ACK
↓ timeout / no ACKretry within configured bound
05 / SECURITY OPTIONS AND LIMITS
Implemented mechanisms; no independent security audit
Code and repository security notes describe AES-128-CTR payload encryption, HMAC-SHA256 truncated to a four-byte MIC, and a per-source replay window. The configuration supports no-security, authentication-only and full payload-encryption modes. A pre-shared 16-byte master key derives working keys using the network ID. The MIC construction covers protocol header fields and encrypted payload.
These are implementation details, not a security assurance. The repository contains no independent cryptographic audit or formal security proof. A 32-bit MIC is a documented overhead/security tradeoff. There is no key exchange, certificate trust, forward secrecy, identity attestation, secure boot or jamming protection. The security notes also mark nonce uniqueness across all real reset/power-cycle patterns as unverified. Confirm receive-path security and configuration in the exact integration before relying on the feature.
Do not infer an “authenticated mesh” guarantee. Presence of crypto code and security-mode enums alone does not establish the behavior of a configured deployment or the security of its key lifecycle.
06 / TEST AND PLATFORM EVIDENCE
Host protocol tests; no physical RF measurements
The repository verification record dated 2026-06-27 reports Windows POSIX-port builds using MSVC and ClangCL, with 15/15 CTest tests passing across listed configurations, including security on/off, power and low-memory variants. It lists tests for framing, crypto code paths, routing, network behavior, forwarding and loopback.
ESP32 support has compile/smoke integration evidence in the repository. The same verification and limitations docs say ESP-IDF builds and hardware flashing were not run in that record. No physical RF range, latency, throughput, coexistence, regulatory compliance or battery-current measurements are provided. GitHub Actions is configured but its current pass state was not verified by the local evidence record.
Verification recordSecurity disclosure and limitsNetwork layerKnown limitations
07 / DEPLOYMENT BOUNDARY
Validate the radio environment and threat model
- Do not infer range, latency, throughput or battery life from host tests or protocol constants.
- Routing scalability depends on RF conditions and traffic; the repository marks it unmeasured.
- Security mechanisms have not received independent cryptographic review; nonce lifecycle and deployment configuration need scrutiny.
- A four-byte MIC has a shorter forgery margin than a full-length HMAC and is explicitly a tradeoff.
- Jamming, key distribution, identity provisioning and secure boot are outside the documented implementation.
- Hardware radio and power behavior require testing on the chosen board, firmware and antenna setup.