wangfq
e3eaa111fe
根因(非平台推测的环形缓冲/event_report队列):
mqtt_publish 的 mqttBuf=512B < loop_data(4通道)604B
→ MQTTSerialize_publish 返回 -2 不写 buf
→ len 为 uint32_t, -2 变 42.9亿
→ WCHNET 把清零缓冲+越界相邻全局(temp_guide=report_config→report_c)
当 520B 垃圾包发出 → broker 见非法类型0x00 RST → 重连风暴
修复(net_srv.c):
- MAX_MQTTBUF_LEN 512→1024 (容纳 604B loop_data)
- mqtt_publish: len uint32→int + 守卫 if(len<=0)return (序列化失败绝不发残缓冲)
- keepalive 9→60 (报告建议, 9s过激)
event_report 协议违规修复(iot_mqtt_srv.c):
- 重连重发保持原 msg_id/ts (V1.04 §5.3-2), 不再作废换号致平台去重失效
验证: tests/test_mqtt_publish_overflow.c 复现旧垃圾包+验证守卫/大缓冲;
tests/test_event_report.c T8 断言重连同 msg_id. 均全过.
遗留: ts=上电秒数非Unix时间戳, 待定方案(设备无RTC/SNTP)
Refs: docs/incidents/2026-07-15-DC045A49718F-protocol-error.md
2.5 KiB
2.5 KiB
抓包存档：DC045A49718F MQTT protocol error 风暴
- 文件:
2026-07-15-DC045A49718F-protocol-error.pcap（44 包，20s 窗口） - 抓包时间: 2026-07-15 14:26 左右（设备 14:20 上电后持续复现）
- 抓包点: 腾讯云 159.75.137.141，
tcpdump -i any port 1883 and host 113.91.145.40 - 设备: DC045A49718F (DLD960GA, hard 1.0 / soft 1.0，新版 event_report 重发固件)
现象
设备每 ~1s 被 mosquitto 以 disconnected due to protocol error 踢下线，
15 分钟内 80+ 次重连、87 次 initialize 上报。
pcap 关键证据（用 tcpdump -r <pcap> -nn -ttt -X 查看）
正常序列先走完：
CONNECT (MQTT 3.1.1, client_id=DC045A49718F, u=admin, keepalive=9)
→ CONNACK
→ SUBSCRIBE dld960/DC045A49718F/srv → SUBACK
→ PUBLISH dld960/DC045A49718F/dev {"cmd":"initialize", msg_id:21, ts:393, ...} ← 报文完好
紧接着设备发出致命包：
TCP 段 520 字节 = 前 512 字节全 0x00 + 尾部 8 字节 ASCII "report_c"
0x00不是合法 MQTT 控制报文类型（type 0 保留）→ broker 立即 RST 断连- RST 后设备仍继续发第二个 520B 全零段（seq 805:1325）
诊断
520 = 512 + 8 → 高度疑似 512B 环形 TX 缓冲区回绕(wrap)处理 bug。
推测：往 TX 缓冲写 report_config 响应时跨越回绕边界，"report_c" 落在缓冲区 物理尾部，其余部分绕回头部；发送侧却把整块未初始化（全零）缓冲区一次性发出。 本次固件恰好新增了事件待发队列 + 5s 重发机制（V1.04），动过 TX 路径， 建议重点排查：
- 新待发队列的写指针 / 回绕边界处理
- 重发定时器与主循环并发 publish 的互斥（两个写者交叉写 TX 流）
- 发送长度是否误用缓冲区总长而非报文实际长度
顺带实锤的协议违规（固件侧待修）
- 断线重连后重发事件用了新 msg_id：msg_id 9/10 内容完全相同 (car_leave ch1 value=48, ts=76)，双双入库 → 平台 (dev_serial,msg_id) 去重失效。V1.04 §5.3 条 2：重发必须用相同 msg_id（跨重连也要保持）
- ts 字段是上电秒数（76/393），不是协议约定的 Unix 时间戳
- keepalive=9s 过于激进（老问题），建议 30~60s
平台侧结论（无需改动）
event_report 必答闭环工作正常：ack <1s、回显 msg_id、先落库后应答； msg_id 相同的重复包去重有效。重复入库仅发生在固件违规换 msg_id 的场景。