mirror of
https://github.com/meshtastic/firmware.git
synced 2026-09-27 08:46:23 -04:00
UdpMulticastHandler clears transport_mechanism, pki_encrypted and public_key on arrival but leaves priority, via_mqtt and tx_after as the sender set them. All three are local-only, and the reasoning the BLE ingress already carries applies unchanged here: multicast carries the full proto, so the sender chooses. priority is the one that bites. It is not in the LoRa header, so fixPriority derives it locally for a radio arrival and nothing on that path can be chosen by a stranger. Over UDP a crafted packet can ask for MAX, which outranks the ceiling fixPriority assigns, and replaceLowerPriorityPacket then evicts one of our own frames to make room for it once perhapsRebroadcast queues it. via_mqtt suppresses our uplink for that packet and tx_after schedules our transmit. None of it needs a key, and multicast reaches anyone on the LAN. develop has the same gap, so this is not something the BLE spike introduced - the spike's own bearer was simply hardened and the shipped one was not. Worth its own PR against develop. Also restores two firmware anchors a comment sweep dropped from the BLE priority guard: perhapsRebroadcast is what copies the crafted value into the TX queue and replaceLowerPriorityPacket is what evicts. Native suite 1430/1430.