Pre-release. Rolls up the complete ok_to_mqtt violation-detection feature and its pagination follow-up.
Detect MQTT gateways that ignore ok_to_mqtt
Meshtastic packets carry an ok_to_mqtt bit by which the originating node signals whether it consents to its traffic being uplinked to MQTT. Firmware only enforces it when a gateway relays other nodes' packets, and it skips the check entirely whenever the gateway believes its broker address is private — a plain IP-range test with no awareness of NAT or port forwarding. A gateway reaching its broker through a LAN-literal address that is also port-forwarded gets misclassified as private and silently relays opted-out traffic to what is effectively a public broker.
MeshMonitor now detects that. When a received packet's bit is explicitly clear and the publishing gateway is not the originator, it is a provable violation — and it is recorded.
Important: a violation is almost certainly a gateway misconfiguration, not malice. Treat it as something worth flagging to the gateway's operator.
Where you see it
- Packet Monitor — a
violationbadge on affected packets, and a per-gatewayok_to_mqttcolumn in the packet detail view showing which gateway violated (a packet can be relayed by many). Four states are distinguished: violation, allowed, opted out, and unknown (bit unreadable). - Analysis & Reports → ok_to_mqtt Violations — a cross-source report with a per-gateway summary (violation count, distinct originators affected, sources, first/last seen), drill-down to individual violating packets, window presets (24 h / 7 / 30 / 90 days) or an explicit date range, CSV export, and an optional "include unproven" toggle.
Behaviour worth knowing
- Recording is on by default. Violation history is kept ~90 days in its own store, independent of the MQTT Packet Monitor's much shorter window — so the report works out of the box. The per-packet badge, however, reads the Packet Monitor's capture log, which is opt-in and off by default; the Packet Monitor now says so explicitly when capture is off, so an absence of badges is never mistaken for an absence of violations.
- Forward-only. Detection covers traffic received after upgrading. No backfill is possible — the bit was never previously stored — so expect an empty history at first.
- Confirmed vs. suspected. Rows whose bit could not be read (undecryptable, or captured before this feature existed) are reported as unknown/suspected, never as confirmed violations, and they come from a much shorter retention window.
Included changes
- #4324 — Phase 1: backend detection, migration 128, durable history, cross-source endpoints
- #4328 — Phase 2: Packet Monitor badge + per-gateway attribution
- #4331 — Phase 3: the
ok_to_mqtt Violationsreport - #4332 — fixes #4330: SQL sorting/paging so large result sets page correctly and ascending sorts are accurate
Upgrade notes
Migration 128 adds columns to mqtt_packet_log and creates the violation-history table. It is idempotent and was verified against SQLite, PostgreSQL 16 and MySQL 8.4. The new table is included in migrate-db, so backend-to-backend migrations carry violation history across.
No configuration is required.
🚀 MeshMonitor v4.13.2-rc4
📦 Installation
Docker (recommended):
docker run -d \
--name meshmonitor \
-p 8080:3001 \
-v meshmonitor-data:/data \
ghcr.io/Yeraze/meshmonitor:4.13.2-rc4🧪 Testing
✅ All tests passed
✅ TypeScript checks passed
✅ Docker images built for linux/amd64, linux/arm64, linux/arm/v7
📋 Changes
See commit history for detailed changes.