Meshtasticd crash fixed when transmit power exceeds SX126x limit

Meshtasticd could fall over when a radio was pushed past the SX126x power limit, and that makes the fix matter most for nodes people leave running unattended. In practice, the crash risk was not about a handheld test rig alone. It hit the kind of Linux and MacOS deployments that act as base stations, gateways, and remote monitoring nodes, where a sudden daemon restart can interrupt the mesh backbone other devices depend on.

The issue showed up when runtime configuration changes raised effective transmit power above the SX126x RadioLib ceiling of plus 22 dBm. In the reported setup, a Meshtoad USB SX1262 device was running meshtasticd on Linux with a packaged YAML that had SX126X_MAX_POWER set higher than the chip limit. Once the radio reconfigured, the daemon tripped an assert and restarted with the old settings, so the failure could look like a stubborn configuration change rather than an obvious crash.

That detail matters because meshtasticd is built as a native binary for Linux and MacOS that can turn a computer into a node, send and receive messages, share location, and serve as a gateway or bridge. When that software is sitting in a fixed location and quietly keeping a mesh alive, a restart is not just a nuisance. It can temporarily knock out the infrastructure that handhelds and trackers rely on, especially if an operator is tuning power or LoRa settings on a live deployment.

The newly opened firmware pull request targets that edge case directly. By addressing the crash before the settings change aborts the daemon, it reduces the chance that a node will silently revert to the previous configuration and leave an operator chasing a problem that looks like bad persistence instead of a failed process. That makes the fix feel less like a niche developer cleanup and more like a reliability patch for real Meshtastic infrastructure.