Summary
When a node reboots and loses hardware clock sync, it may transmit telemetry packets with severely incorrect timestamps (months or years off). MeshMonitor accepts these timestamps as authoritative and renders them on the chart X-axis, causing extreme distortion in all telemetry graphs.
Steps to Reproduce
- Have a node lose clock sync (e.g., reboot without NTP/GPS fix)
- Node transmits telemetry with stale/incorrect hardware clock timestamps
- Open any local node telemetry view (Air Utilization, Altitude, Channel Utilization, Device Uptime, Voltage, SNR)
- Observe the "Last 72 Hours" X-axis
Observed Behavior
The X-axis spans months instead of 72 hours. Example labels seen simultaneously:
Jun 4 6:59 PMFeb 12 1:06 PMOct 24 9:13 AMAug 19 5:05 PM
This affects all local node telemetry charts at once when a single node sends bad timestamps.
Expected Behavior
One of the following mitigations should apply:
- Option A: Use server receipt time (
received_at) instead of (or as a fallback for) the packet's embedded timestamp when the embedded timestamp falls outside a reasonable window (e.g., ±24h from server time)
- Option B: Drop/reject telemetry packets whose timestamps are outside a configurable validity window before storing them
- Option C: Clamp the chart X-axis to the requested time range (e.g., last 72 hours) and exclude outlier data points from the rendered view
Impact
- All telemetry charts become unreadable when any connected node has a bad clock
- Future timestamps (which should be impossible) appear in historical views
- No visible warning is shown to the user about the invalid data
Environment
- View: Last 72 Hours Telemetry
- Affected charts: Air Utilization, Altitude, Channel Utilization, Device Uptime, Voltage, SNR
Authored by NodeZero 0️⃣
Summary
When a node reboots and loses hardware clock sync, it may transmit telemetry packets with severely incorrect timestamps (months or years off). MeshMonitor accepts these timestamps as authoritative and renders them on the chart X-axis, causing extreme distortion in all telemetry graphs.
Steps to Reproduce
Observed Behavior
The X-axis spans months instead of 72 hours. Example labels seen simultaneously:
Jun 4 6:59 PMFeb 12 1:06 PMOct 24 9:13 AMAug 19 5:05 PMThis affects all local node telemetry charts at once when a single node sends bad timestamps.
Expected Behavior
One of the following mitigations should apply:
received_at) instead of (or as a fallback for) the packet's embedded timestamp when the embedded timestamp falls outside a reasonable window (e.g., ±24h from server time)Impact
Environment
Authored by NodeZero 0️⃣