docs: record v1.1.1 dirty-network recovery design

项目技术实现.md

@@ -246,6 +246,55 @@ EN,LPORT,RIP,RPORT,UART
 
 该结果说明修复后工程仍满足 `STM32F103R8T6` 的 `20KB RAM` 上限，但余量已经很小；后续若继续增加功能，应优先考虑复用现有缓冲与状态，而不是增加新的静态大数组。
 
+### 6.3 客户现场脏网络恢复增强
+
+客户现场换 PC 后曾出现设备持续 ARP、`ping` 不通、TCP Client 不恢复的现象。抓包显示故障前后存在 IPv6、DHCPv6、mDNS、IGMP、LLDP 等与当前业务无关的网络噪声；当前固件为静态 IPv4、TCP2UART 与 ICMP 诊断模型，不依赖 UDP、IPv6、DHCP 或多播发现。
+
+本阶段采用低 RAM 优先的恢复策略，不先扩大 `PBUF_POOL_SIZE`，而是在更靠近入口的位置减少无关帧对 lwIP pool 的占用：
+
+1. `TCP Client CONNECTING` 增加应用层超时：
+   - `TCP_CLIENT_CONNECT_TIMEOUT_MS = 10000`
+   - `tcp_connect()` 返回 `ERR_OK` 后记录 `connect_start_ms`
+   - `tcp_client_poll()` 发现 `CONNECTING` 超过超时时间后，注销回调、`tcp_abort()` 当前 PCB、释放 `hold_pbuf`，再按原有 `reconnect_interval_ms` 重连
+   - `tcp_client_status_t.connect_timeout_count` 记录发生次数
+2. `CH390` RX 入口增加 `pre-pbuf` 协议过滤：
+   - 在 `pbuf_alloc(PBUF_RAW, ..., PBUF_POOL)` 之前先读取以太网头与最小 IPv4 头
+   - 允许进入 lwIP 的协议限定为 `ARP`、`IPv4 ICMP`、`IPv4 TCP`
+   - 默认丢弃 `IPv6`、`IPv4 UDP`、`IPv4 IGMP`、`LLDP`、未知 EtherType 与畸形头
+   - 丢弃帧只跳过 CH390 RX FIFO 剩余字节，不分配 pbuf
+3. 软件 MAC 过滤暂不启用：
+   - 第一版只做协议层过滤，避免误杀广播 ARP 或未来硬件过滤策略变化
+   - 目的 MAC 相关判断保留为后续可选增强
+
+新增 CH390 诊断字段用于现场判断是否仍存在资源压力：
+
+1. `rx_pbuf_alloc_failed`
+2. `rx_filtered_frames`
+3. `rx_filtered_ipv6`
+4. `rx_filtered_udp`
+5. `rx_filtered_igmp`
+6. `rx_filtered_lldp`
+7. `rx_filtered_other_eth`
+8. `rx_filtered_other_ipv4`
+9. `rx_filtered_malformed`
+10. `rx_ipv4_icmp_frames`
+11. `rx_ipv4_tcp_frames`
+12. `rx_ipv4_udp_frames`
+
+验收口径：
+
+1. 正常 `ARP / ping / TCP Server / TCP Client` 功能不受影响
+2. 客户脏网络中的 IPv6、UDP、IGMP、LLDP 噪声不会进入 lwIP pbuf pool
+3. 若远端 TCP Server 不监听或静默丢 SYN，TCP Client 不再永久停留在 `CONNECTING`
+4. 若过滤后 `rx_pbuf_alloc_failed` 仍持续增长，再评估从无关功能中回收 RAM 并调整 `PBUF_POOL_SIZE`
+
+本阶段 Keil 构建验收结果：
+
+1. `errors = 0`
+2. `warnings = 0`
+3. `flash_bytes = 57404`
+4. `ram_bytes = 20440`
+
 ## 七、主循环实现方向
 
 主循环仍保持裸机轮询风格：