cognitum-agent 0.22.7: mesh threads panic every boot; mesh receive path dead; binary attestation 'unknown'

[markt-heximal]

Component: cognitum-agent mesh subsystem · firmware 0.22.7 (OTA) · Raspberry Pi seed

Summary

On 0.22.7, three mesh worker threads panic on every boot, the mesh receive path stays at 0 bytes, and the build is rejected by attestation — so seeds never sync and fleet rollups go stale.

Evidence

• Deterministic panics each boot (reproducible via systemctl restart cognitum-agent):
  • mesh-bridge — src/cognitum-agent/src/mesh/mod.rs:353:69
  • mesh-keepalive — src/cognitum-agent/src/mesh/mod.rs:1028:84
  • mesh-sync — src/cognitum-agent/src/mesh/mod.rs:1276:25
• GET /api/v1/mesh/status: connected_peers > 0 but total_bytes_received: 0 (MBs sent, nothing received); every peer is Relayed/Idle, connection_type: "None".
• Repeating log: [mesh] WARNING: binary attestation UNKNOWN — control plane does not recognize this binary.
• GET /api/v1/mesh/peers contains an entry whose device_id is non-UTF8 / corrupt — a likely trigger for the mod.rs:353 panic (unchecked parse/slice on peer identity).

Impact

Seed↔control-plane sync is dead; the agent keeps running with the mesh threads dead, so the device looks alive locally but never updates the fleet. High.

Asks

1. Guard the peer-identity parse at mesh/mod.rs:353 against malformed/non-UTF8 device_id.
2. Investigate the one-way mesh (0 bytes received) on 0.22.7.
3. Document/repair attestation allowlisting so OTA builds aren't flagged "unknown".

[ruvnet]

Closing: off-topic. This issue describes cognitum-agent and a Raspberry Pi seed fleet — components that are not part of this project (wifi-densepose / RuView). Please file against the correct repository.

---

Generated by Claude Code