Meshtastic固件中MQTT TLS连接导致设备重启循环问题分析

问题背景

在Meshtastic固件v2.5.22.d1fa27d版本中，当启用MQTT服务器的TLS功能时，设备会在WiFi启动后立即进入崩溃重启循环。这个问题主要影响Heltec V3和Station G2等ESP32设备。

问题现象

设备在以下条件下会出现异常：

1. 启用了MQTT TLS加密连接
2. WiFi连接成功后立即尝试建立MQTT连接
3. 设备进入崩溃重启循环
4. 经过长时间(约30分钟)后可能偶然成功建立TLS连接

技术分析

根本原因

问题根源在于ESP32的任务栈空间分配不足。具体表现为：

1. WiFi连接成功后，系统通过WiFiEvent回调触发MQTT连接
2. 该回调运行在arduino_events任务中，该任务仅有4096字节栈空间
3. TLS连接建立过程需要更多内存资源，导致栈溢出
4. 系统检测到栈溢出后触发看门狗重启

代码层面分析

在WiFiAPClient.cpp中，WiFi连接成功后会立即调用mqtt->reconnect()。这个调用发生在内存受限的WiFi事件回调上下文中，而TLS连接需要更多栈空间。

相比之下，当初始连接失败后，MQTT的重试逻辑运行在主循环(loop)中，该任务有8192字节栈空间，因此能够成功建立TLS连接。

解决方案

推荐修复方案

建议移除WiFi连接成功后的立即重连逻辑，改为依赖MQTT模块自身的重试机制。具体修改如下：

1. 删除WiFiAPClient.cpp中的立即重连代码
2. 完全依赖MQTT::runOnce的周期性重试机制(每5秒一次)
3. 主循环任务有更大的栈空间，能够处理TLS连接的内存需求

额外改进建议

1. 当使用默认MQTT服务器时，应自动禁用TLS选项
2. 在固件层面增加配置验证逻辑，防止无效配置
3. 对于公共MQTT服务器，应强制禁用TLS功能

技术影响

此修复将带来以下改进：

1. 提高TLS连接的稳定性
2. 减少不必要的内存消耗
3. 保持原有的连接重试功能
4. 消除潜在的崩溃风险

实现建议

对于开发者而言，建议：

1. 优先采用主循环任务处理资源密集型操作
2. 避免在事件回调中执行复杂操作
3. 为TLS连接预留足够栈空间
4. 增加配置参数的合理性检查

此问题的解决不仅修复了崩溃问题，还优化了Meshtastic固件的MQTT连接处理机制，为后续功能扩展奠定了更好的基础。