mirror of
https://github.com/agessaman/meshcore-bot.git
synced 2026-09-01 16:48:26 +00:00
Two fixes from the previous round were incomplete: - The scheduled-message chunk budget used the schedule's explicit scope, but send_channel_message resolves an unset scope from flood_scope.<channel> and then outgoing_flood_scope_override. A schedule with an implicit regional scope was therefore sized for a global send and every chunk could overshoot once the sender added the regional header. The budget now resolves the effective scope, and assumes regional if that resolution fails, since guessing regional only ever makes chunks smaller. - Resetting _last_path_distance_km per request fixed sequential reuse but not concurrency: the decode awaits a database lookup, and the dispatcher runs handlers as independent tasks, so two path commands can interleave and render each other's distance. The distance now rides on the request's own message, with the instance attribute kept only as a fallback for direct calls. Two new findings: - rf_data_is_correlated() treated pubkey and partial-prefix matches as packet-unique, but a sender prefix identifies a sender, not one transmission. With several cached packets from the same sender, the first (usually oldest) was returned and allowed to supply a route. Those strategies now take the newest match and are authoritative only when the match is unambiguous; otherwise the entry is marked fallback, so it still provides SNR/RSSI but never a route. - The flood_scopes allowlist accepted a scope resolved from an uncorrelated fallback packet. The HMAC proves the cached packet is in an allowed scope, not that this message is, so a recent allowed-scope packet could admit an unrelated message. Scope authorisation now requires packet-bound correlation and logs plainly when it does not have it. That last one is a deliberate fail-closed change to an authorisation path that predates tonight. Channel messages normally carry raw_hex and correlate exactly, so the fallback is the exception rather than the rule, but a deployment using flood_scopes will now stay quiet in cases where it previously replied on an assumed scope.