Meshtastic alpha bug hides successful encrypted admin commands from controllers

A Meshtastic node could quietly accept a PKI-encrypted admin change and still look dead to the controller. That is the trap surfaced in issue #10443, where a Heltec V3 running firmware 2.7.23.b246bcd processed the change on-node but never delivered the routing acknowledgement back up the mesh.

That matters most when the node is unattended. In that situation, a timeout reads like failure, even if the settings were already written. An operator may resend the same command, burn time chasing a phantom problem, or assume the remote node never heard the request at all. For meshes used to manage distant boxes, that false negative is worse than a clean error because it hides success behind missing feedback.

The bug hit command-style admin verbs, not the read path. The report named commit_edit_settings, set_channel, set_config, set_module_config, and set_owner as affected. Read-style verbs kept working because their replies used ADMIN_APP rather than ROUTING_APP. The broken path was more subtle: AdminModule created an auto-generated ROUTING_APP reply when a command did not generate its own response, then tagged it as PKI encrypted. Router.cpp later excluded ROUTING_APP packets from the PKC encoding branch, so the packet fell into the error path and was dropped before transmission.

The firmware context makes the failure more awkward, not less. Meshtastic 2.7.23.b246bcd was an alpha pre-release published two days before the issue report, so this was not a stale branch buried in old code. It was the current alpha train, with recent enhancements and bug fixes moving through the same PKI plumbing. The issue description proposed two fixes: allow PKI-encrypted ROUTING_APP replies in the relevant path, or clear the PKI flag on the auto-generated routing reply.

The remote-admin docs explain why this needs careful handling in the first place. Meshtastic calls remote node administration an advanced feature, warns that careless settings can disconnect a node from the mesh, and says firmware 2.5 and later uses the local node’s public key in the remote node’s Admin Key fields, with up to three unique Admin Keys per node. The security docs also say firmware 2.5.0 introduced PKC for direct messages and Session IDs for admin messages, while 2.4.x and earlier relied on a legacy shared-PSK admin channel. That is why this bug stings: the command can succeed, the node can move on, and the controller can still be left staring at a timeout.