Fix for preserving pki_encrypted and public_key when relaying UDP multicast packets to radio.#9916
Conversation
…ticast packets to radio. PKI DMs sent over UDP multicast had their pki_encrypted flag and public_key fields explicitly cleared before being forwarded to the LoRa radio. This caused the receiving node to treat the packet as a channel-encrypted message it couldn't decrypt, silently dropping it. The MQTT ingress path correctly preserves these fields. The UDP multicast ingress path should behave the same way.
|
|
@niklaswall, Welcome to Meshtastic!Thanks for opening your first pull request. We really appreciate it. We discuss work as a team in discord, please join us in the #firmware channel. Welcome to the team 😄 |
There was a problem hiding this comment.
Pull request overview
Fixes UDP multicast ingress so PKI direct messages forwarded from LAN to LoRa retain PKI metadata (pki_encrypted and public_key), matching the behavior of the MQTT ingress path and preventing silent drops on the receiving node.
Changes:
- Stop forcibly clearing
mp.pki_encryptedandmp.public_keywhen decoding and relaying UDP multicast packets. - Preserve PKI fields on UDP multicast ingress so PKI DMs are handled correctly by the router/decrypt path.
You can also share your feedback on Copilot code review. Take the survey.
Zeroize MeshPacket before decoding to prevent data leakage. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
@jp-bennett tagging you since this was added in a97df4b |
|
Yes, it would be interesting to know why it was added! The commit message "Sanity check incoming UDP" does not really make sense since we were basically just "dropping" parts of the MeshPacket related to PKI encryption (pki_encrypted and public_key). My best guess is that you might sometimes end up with garbage in the MeshPacket since memory was not initialized before decoding the protobuf. Initializing MeshPacket to meshtastic_MeshPacket_init_zero before decoding the received data should fix that potential issue. |
…ticast packets to radio. (#9916) * Fix for preserving pki_encrypted and public_key when relaying UDP multicast packets to radio. PKI DMs sent over UDP multicast had their pki_encrypted flag and public_key fields explicitly cleared before being forwarded to the LoRa radio. This caused the receiving node to treat the packet as a channel-encrypted message it couldn't decrypt, silently dropping it. The MQTT ingress path correctly preserves these fields. The UDP multicast ingress path should behave the same way. * Zeroize MeshPacket before decoding Zeroize MeshPacket before decoding to prevent data leakage. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
…ticast packets to radio. (meshtastic#9916) * Fix for preserving pki_encrypted and public_key when relaying UDP multicast packets to radio. PKI DMs sent over UDP multicast had their pki_encrypted flag and public_key fields explicitly cleared before being forwarded to the LoRa radio. This caused the receiving node to treat the packet as a channel-encrypted message it couldn't decrypt, silently dropping it. The MQTT ingress path correctly preserves these fields. The UDP multicast ingress path should behave the same way. * Zeroize MeshPacket before decoding Zeroize MeshPacket before decoding to prevent data leakage. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Fix for preserving pki_encrypted and public_key when relaying UDP multicast packets to radio.
PKI DMs sent over UDP multicast had their pki_encrypted flag and public_key fields explicitly cleared before being forwarded to the LoRa radio. This caused the receiving node to treat the packet as a channel-encrypted message it couldn't decrypt, silently dropping it.
The MQTT ingress path correctly preserves these fields. The UDP multicast ingress path should behave the same way.
🤝 Attestations