From 4b78e0d36cc69b533f198d3d96748286e35e8cd3 Mon Sep 17 00:00:00 2001 From: Wanderingss <1624155937@qq.com> Date: Tue, 22 Sep 2026 06:15:57 +0800 Subject: [PATCH] =?UTF-8?q?D20=E8=B0=83=E6=9F=A5=E8=AE=B0=E5=BD=95?= =?UTF-8?q?=E4=BF=AE=E6=AD=A3=EF=BC=9A=E6=8F=90=E4=BA=A4=E5=89=8D=E6=97=A5?= =?UTF-8?q?=E5=BF=97=E5=A4=8D=E6=A0=B8=E7=A1=AE=E8=AE=A4=E6=88=90=E8=B4=A5?= =?UTF-8?q?=E5=B7=AE=E5=BC=82=E4=B8=BA=E9=A6=96=E6=AC=A1accept=E4=B8=8E?= =?UTF-8?q?=E5=BB=B6=E8=BF=9FDISCONNECT=E4=BA=8B=E4=BB=B6=E7=9A=84?= =?UTF-8?q?=E7=AB=9E=E6=80=81=EF=BC=88=E6=9C=AA=E6=94=B9=E4=BB=A3=E7=A0=81?= =?UTF-8?q?=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/测试说明/链路时延实测数据分析.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/docs/测试说明/链路时延实测数据分析.md b/docs/测试说明/链路时延实测数据分析.md index 7461e2b3..157c47bd 100644 --- a/docs/测试说明/链路时延实测数据分析.md +++ b/docs/测试说明/链路时延实测数据分析.md @@ -209,7 +209,7 @@ peer 侧三次"断开 → 1.5s → 重连"（`--reconnect-rounds 3`）： | **D17** | **INIT 应答把 u32 截成 6B → 帧字节数字段恒 0** | M3：真机与模拟器均 `framebytes=0`（应为 3200） | **已修复并验证**（发满 8B → `framebytes=3200`；§7.1） | | **D18** | **多打点站点共用全局探针窗口 → 跨段污染** | M3 run17：prod/relisten 都读出 ui_loop 的 ~11ms 值 | **已修复**（`lat_probe_add_seg` 按段名过滤） | | **D19** | **Phase 14 漏调 `lat_time_init()` → 全 0 假绿** | M3 run16：三段全 0 却 `verdict=OK` | **已修复**（补初始化 + med==0 判无效） | -| **D20** | **FTP 同一会话的第 2 个数据连接失败（425）** | 复现条件已量化：**每次开机后的第一个 FTP 会话**在该会话第 2 个数据连接处失败（之后的会话 4/4 全通过）；设备日志签名 = 数据连接 accept 后约 10~20ms 出现 `DISCONNECTED, releasing (chip tcp=0x00)` → `data socket closed, accept aborted` → 425 | **已定位未修**（详见 §7.4）：属芯片"同一 Socket 快速复用（关闭→重开）"的时序竞态；两次修法（优雅断开+复用监听器 / relisten 兜底）都不稳定已回退；**保留安全硬化**（陈旧 DISCONNECT 甄别 + 两处 1 字节栈越界修复）；复现脚本 `test/ftp_regression.py` | +| **D20** | **FTP 同一会话的第 2 个数据连接失败（425）** | 复现条件已量化：**每次开机后的第一个 FTP 会话**在该会话第 2 个数据连接处失败（之后的会话 4/4 全通过）；设备日志签名 = 数据连接 accept 后约 10~20ms 出现 `DISCONNECTED, releasing (chip tcp=0x00)` → `data socket closed, accept aborted` → 425 | **已定位未修**（详见 §7.4，2026-09-22 日志复核修正机理见 §7.4.1）：属芯片"同一 Socket 快速复用（关闭→重开）"的时序竞态；两次修法（优雅断开+复用监听器 / relisten 兜底）都不稳定已回退；**保留安全硬化**（陈旧 DISCONNECT 甄别 + 两处 1 字节栈越界修复）；复现脚本 `test/ftp_regression.py` | | **E-02** | 空闲 FTP 控制连接冻结 netTask（头阻塞） | M3：受压帧 **17718ms**（`QUIT` 即恢复） | **已修复并验证**（→ **74.7ms** med / 106.8ms max，零尖峰；§7.1） | > D17/D18/D19 为本轮 M3 自查发现（D18/D19 属测试工装缺陷，会导致"绿而无效"的数据）； @@ -266,6 +266,7 @@ sock4 auto-relisten ok / relisten retry ok ← 监听器随后自行恢 ``` **机理（已定位）**：FTP 数据通道每次传输结束都要 `net_close`（对端以 EOF 判"传完"），随后下一次 PASV 又要在**同一芯片 Socket**上 `net_socket/bind/listen` 重开；在开机首个会话的时序下，上一条连接的 teardown 与本次重开交叠，芯片在新连接建立后立刻将其拆除（读到 chip TCP = CLOSED）。与 D10（Trap 09 沉降）、D14（静默回收）同属"单连接 Socket 复用"家族。 +〔2026-09-22 提交前日志复核修正：该 DISCONNECT 在**成功**会话中同样出现且其后数据照常读出，"芯片拆除新连接"不成立；失败的真实判据是**延迟 DISCONNECT 事件与首次 accept 的先后竞态**，详见 §7.4.1。〕 **试过但未采用的修法**（均已回退，保留结论备查）： @@ -286,6 +287,20 @@ sock4 auto-relisten ok / relisten retry ok ← 监听器随后自行恢 3. **寄存器级定位**：在首会话复现窗口内打印 `CMD_GET_SOCKET_STATUS_SN`（2 字节）与 SINT 序列，确认芯片在 teardown/reopen 交叠时的内部状态迁移； 4. 复现脚本：`test/ftp_regression.py --host `（单会话内 7 次数据连接 + 1KB/32KB 往返内容校验，退出码 = 是否全通过）。 +#### 7.4.1 补充：提交前串口日志复核（2026-09-22，纯日志分析，未改代码） + +对台架串口日志（00:26~00:27 窗口，含失败会话与紧随其后的多个成功会话）逐行复核，机理修正如下： + +1. **DISCONNECT 事件在成功会话中同样出现**：成功会话的 STOR 数据连接在 `standalone accept` 后约 31ms 同样上报 `sock4 DISCONNECTED, releasing (chip tcp=0x00)`，但其后数据照常读出（`recv sock4 len=1027`）、传输完成 → 该事件**不是**"芯片拆除新连接"，而是**上一条数据连接（LIST 通道，服务端 `net_close`）的延迟断开事件**落在同一芯片 Socket 上（`net_close_locked` 的排空窗口结束后芯片才补报）； +2. **成败唯一差异 = 竞态**：失败会话中 lftpd 的首次 `net_accept`（`lftpd_inet_accept_timeout`）运行在 DISCONNECT 事件**之后**（state 已置 CLOSED → `data socket closed, accept aborted` → 425）；成功会话中首次 accept 抢在事件之前（state=ESTABLISHED 立即返回），其后的 DISCONNECT 不影响数据路径——MCU 侧 CLOSED 状态不妨碍从芯片缓冲读数据（fun_para bit3=1 保留缓冲）； +3. **现有甄别为何拦不住**：延迟 DISCONNECT 时刻 `ch395f_get_socket_status` 回读 `tcp=0x00`，不反映新连接的 ESTABLISHED 态 → "回读芯片状态判陈旧"的甄别条件（`st[1]==ESTABLISHED` 才丢弃）在此场景恒不成立，只能防"芯片状态仍 ESTABLISHED"的另一类陈旧事件； +4. **对修法方向的修正**： + - **数据 Socket 轮换（优先，结论不变）**：连续数据连接落在不同芯片 Socket，直接消除"上一条连接的断开事件打到下一条新连接"的路径； + - 备选：已 accept 的连接对迟到 DISCONNECT 免疫（成功会话已证明数据路径不受影响）——但须同时处理"事件先到、accept 后到"的顺序，单做此项不能覆盖失败场景； + - 客户端重试（425 属 RFC 959 瞬态 4xx）作为现场规避手段不变。 + +> 注：D20 修复按用户指示**暂缓**（2026-09-22）；本节仅修正调查记录，未改任何代码。 + ### 7.5 建议的后续项（按性价比） 1. **尾批 ~52ms（占一帧 77%）—— 已定性并给出解法（§3.3）**：客户端在帧未收齐时补发一个字节