MAP_REPORT_APP handler overwrites node position without validating latitude_i/longitude_i #64

New Issue

2026-10-05T06:04:31+02:00

adam commented

2026-10-05 06:04:31 +02:00

In meshview/mqtt_store.py, the MAP_REPORT_APP branch of process_envelope() writes Node.last_lat/last_long straight from the decoded MapReport with no validation at all:

# existing node update
node.last_lat = map_report.latitude_i
node.last_long = map_report.longitude_i

# new node insert
last_lat=map_report.latitude_i,
last_long=map_report.longitude_i,

This is different from the POSITION_APP branch a bit further down, which at least guards against a zeroed-out GPS fix:

if position and position.latitude_i and position.longitude_i:
    ...
    node.last_lat = position.latitude_i
    node.last_long = position.longitude_i

Since Node keeps a single row per node_id (last-write-wins, no history), a node that sends a MapReport before it has a GPS fix (latitude_i == 0, or a partial/garbage fix) silently overwrites a previously-good position. There's no way to recover the old value from the API afterwards — any consumer of /api/nodes (e.g. last_lat/last_long) will just see the node jump to (0, lon) or similar until the node happens to send another valid report.

We hit this downstream in a community map project (meshtastic-es-map) that consumes /api/nodes: some nodes were rendering at wildly wrong locations (near the equator or the Greenwich meridian) because a stale latitude_i == 0 (with a real longitude_i) had come from a MapReport and slipped through both meshview and our own null-island filter (ours only checked abs(lat) < 0.5 and abs(lon) < 0.5, i.e. required both axes near zero — same class of bug).

Suggested fix: apply the same "ignore truthy-zero fix" guard used in the POSITION_APP branch to MAP_REPORT_APP as well, e.g.:

if map_report.latitude_i and map_report.longitude_i:
    node.last_lat = map_report.latitude_i
    node.last_long = map_report.longitude_i

(and the equivalent for the insert-new-node path). Happy to send a PR if useful.

In `meshview/mqtt_store.py`, the `MAP_REPORT_APP` branch of `process_envelope()` writes `Node.last_lat`/`last_long` straight from the decoded `MapReport` with no validation at all: ```python # existing node update node.last_lat = map_report.latitude_i node.last_long = map_report.longitude_i ``` ```python # new node insert last_lat=map_report.latitude_i, last_long=map_report.longitude_i, ``` This is different from the `POSITION_APP` branch a bit further down, which at least guards against a zeroed-out GPS fix: ```python if position and position.latitude_i and position.longitude_i: ... node.last_lat = position.latitude_i node.last_long = position.longitude_i ``` Since `Node` keeps a single row per `node_id` (last-write-wins, no history), a node that sends a `MapReport` before it has a GPS fix (`latitude_i == 0`, or a partial/garbage fix) silently overwrites a previously-good position. There's no way to recover the old value from the API afterwards — any consumer of `/api/nodes` (e.g. `last_lat`/`last_long`) will just see the node jump to (0, lon) or similar until the node happens to send another valid report. We hit this downstream in a community map project (meshtastic-es-map) that consumes `/api/nodes`: some nodes were rendering at wildly wrong locations (near the equator or the Greenwich meridian) because a stale `latitude_i == 0` (with a real `longitude_i`) had come from a `MapReport` and slipped through both meshview and our own null-island filter (ours only checked `abs(lat) < 0.5 and abs(lon) < 0.5`, i.e. required *both* axes near zero — same class of bug). Suggested fix: apply the same "ignore truthy-zero fix" guard used in the `POSITION_APP` branch to `MAP_REPORT_APP` as well, e.g.: ```python if map_report.latitude_i and map_report.longitude_i: node.last_lat = map_report.latitude_i node.last_long = map_report.longitude_i ``` (and the equivalent for the insert-new-node path). Happy to send a PR if useful.

adam closed this issue

2026-10-05 06:04:31 +02:00

adam commented

2026-10-05 06:04:32 +02:00