Meshtastic range-test bug breaks iOS sender configuration path

Meshtastic’s range-test feature hit a classic cross-client drift problem: the firmware accepted one half of the setup, but the iOS admin path would not reliably set the other. In issue 10694, opened June 11, 2026, `range_test.enabled` worked through PKI Admin, while `range_test.sender` would not stick when the setting was sent as an integer from the iOS app.

That is more than a nuisance. Range-test is built for measuring communication range between two nodes, not for decoration in a settings menu. Meshtastic’s documentation says the sender is the fixed node that sends sequential packets, while the receiver can save received packets along with GPS coordinates to a CSV file. The same docs warn that the module burns a lot of airtime, can slow the mesh, and can spam the channel, which is why it should be turned off when it is not in use.

The configuration path matters because the module is controlled through an admin message carrying a `ModuleConfig.RangeTestConfig` protobuf. If that schema changes during a module revamp and every client does not update in lockstep, the result is exactly the kind of split behavior this bug shows. One field can still work, while another field silently fails, leaving an operator with a node that is only half-configured and a test run that does not match the intended role assignment.

Meshtastic’s docs also note that range-test config is available on Android and Apple clients, so this is not a niche edge case. If iOS cannot set the sender role consistently, then a phone that should be able to launch a controlled test from the field becomes less dependable for route checks, deployment validation, and quick link tests. The module’s automatic 8-hour shutoff makes the sender state even more important, because the sender flag defines whether packets are flowing at all.

The bug lands in a familiar corner of the project’s history. An earlier report from October 24, 2025 described a CLIENT_BASE node that seemed to start sending range-test packets only after it was switched to CLIENT in the iPhone app, and a collaborator clarified that the 8-hour limit applies to packet sending, not the module itself. Taken together, the two reports point to the same underlying risk: range-test only stays useful if firmware, iOS, and the rest of the client stack keep the same contract about what a sender is and how it gets set.