mirror of
https://github.com/agessaman/meshcore-bot.git
synced 2026-09-13 03:15:37 +00:00
agessaman
9627230b55
MeshCore's CHAN payload carries neither raw_hex nor a pubkey prefix, so a channel message has no correlation key and find_recent_rf_data always lands on the most-recent-packet fallback. rf_data_is_correlated() is therefore never true for one, and _is_confirmed_global_flood could never pass: across three log files every one of 45 received channel messages was rejected. I raised this when the gate went in and accepted the counter that the handler already has the general RF correlation and decoded packet info for this message's own packet. That holds for DMs and is false for channel messages. '*' asks one question—was this a scoped regional flood?—and there is a second way to answer it that the handler already computes and then discards. A scoped message travels as TRANSPORT_FLOOD GRP_TXT, so if no such packet is anywhere in the RF window, the message cannot have been scoped. That is a window-wide fact, so unlike a route type read off a fallback row it does not depend on having picked the right cached packet. Correlated rows stay authoritative: a correlated TRANSPORT_FLOOD is still blocked even when the scope window is empty, so an empty window cannot launder a message the radio positively identified as scoped. Replaying the real packets from the log, the 43 plain-FLOOD messages now get a reply and the 2 that had a TC_FLOOD GRP_TXT alongside them still fail closed.