wandering1/STM32F4-Base
1
0
Fork 0
Code Issues 29 Pull Requests 1 Actions Packages Projects 2 Releases Wiki Activity

W5波+N-19收口：FTP鉴权落地、Trap25三连定案修复(N-30)、N-20/N-23/N-26

Browse Source 
N-19 FTP 鉴权：
- lftpd_auth（USER/PASS 状态机 + 连续5次失败锁60s）+ SHA-256
  (user||pwd) 口令哈希；config.ini [ftp] 段 user/pwd_hash/write，
  出厂 admin/admin 在用有启动告警；lftpd_log.c 删除并入 lftpd_auth
- ftp_cfg 配置读写；台架 ftp_auth_bench.py 13/13

N-30 / Trap 25（CH395F_Trap_Records.md 四次定案全记录）：
- 修复1 closed-with-data accept：客户端发完正常 FIN 后芯片按
  FUN_PARA(0x09) §5.52② 保留 Socket+RX 缓冲，旧代码把 CLOSED 一律
  relisten 自毁缓冲 → STOR 必挂 425；改为接受"已关但可读"连接排空
- 修复2 丢 CONNECT 中断探针 net_lost_connect_probe + last_peer_port
  幽灵甄别（拆链窗口握手完成但中断丢失，双信源去抖补 accept）
- 修复3 send_list/send_nlst 批量单发：背靠背 ~60B 小段毒化芯片 TX
  （芯片报 SEND_OK 但对端全丢），整份目录一次性写入
- 证伪存档：固定沉降/Socket 轮换冷却/listen 门控（台架 v7 矩阵）
- 台架工具 test/board/ch395f_reuse_bench.{c,h} + host 脚本存档
  （不注册编译；实验分支 n30-chip-bench 保留）

N-20：Error_Handler 死循环降级（记录+复位路径）
N-23：scripts/check_registration.py 双端注册反向校验（pre-commit）
N-26：GD5F NAND 直 DMA 调用方缓冲窗口断言

验证：BUILD_OK 0/0；ftp_regression 连跑 4 轮 11/11（修复前
LIST#4/#7 100% 挂、STOR#2 曾 100% 425）；ftp_auth_bench 13/13；
@test 启动标记 PASS；ci_local L0+L0.5 全过；doc-links 通过。
登记簿 N-30 已销项。
This commit is contained in:
Wanderingss
2026-10-11 18:50:24 +08:00
parent eddbedeee8
commit d1e6bb4ba7
75 changed files with 3928 additions and 352 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/问题记录/CH395F_Trap_Records.md
+96 -8
View File
@@ -19,7 +19,7 @@
### 注意事项
- 数据 Socket 不调 `OPEN_SOCKET`，由 CH395F 在连接到达时自动打开
- DISCONNECT 后 CH395F 自动关闭 Socket，但保留协议/端口/缓冲区配置，可被再次分配
- 手册 §9.2.6 要求数据 Socket **先设源端口再设协议类型**（与监听 Socket 顺序相反）
- `docs/芯片手册/CH395F.md` §9.2.6 要求数据 Socket **先设源端口再设协议类型**（与监听 Socket 顺序相反）
### 对应文件
`Drivers/BSP/NET/net_socket.c` → `net_listen()`
@@ -35,7 +35,7 @@ Phase 8 压力测试，2025-07
多连接模式下多个 Socket 数据互相覆盖，收到错误数据或客户端挂死。
### 根因
CH395F 默认只为 Socket 0~3 各分配独立收发缓冲（共 48 块 × 512B 用满，见手册 §5.45），Socket 4~7 为零块。`net_listen()` 未对 Socket 4~7 显式分配独立缓冲区块，后续代码误用相同块号（如 28~31）导致数据重叠。
CH395F 默认只为 Socket 0~3 各分配独立收发缓冲（共 48 块 × 512B 用满，见`docs/芯片手册/CH395F.md` §5.45），Socket 4~7 为零块。`net_listen()` 未对 Socket 4~7 显式分配独立缓冲区块，后续代码误用相同块号（如 28~31）导致数据重叠。
### 解决方案
每个数据 Socket 独占 4 个缓冲区块（2 发 + 2 收），按 `ds * 4` 基址分配，确保不重叠：
@@ -496,14 +496,14 @@ NET 层 TCP Client（阶段 7）`net_connect()` 返回 0，但 `net_poll()` 报
### 解决
1. `net_init`：`ch395f_set_fun_para(0x09)`（bit0=1, bit1=0, bit3=1）。
2. `ch395f_init()` 之后，循环 0~7 用 `ch395f_set_send_buf(sock, i*6+4, 2)` / `ch395f_set_recv_buf(sock, i*6, 4)` 给每个 Socket 分配独立收发缓冲。按手册 §5.45（48 块 × 512B = 24KB）+ §9.2.8 最优分配：每 Socket 6 块 = 接收 4 块(2KB) + 发送 2 块(1KB)，`ch395f_set_tcp_mss(1024)`，恰好用尽 0~47 块、互不重叠。
2. `ch395f_init()` 之后，循环 0~7 用 `ch395f_set_send_buf(sock, i*6+4, 2)` / `ch395f_set_recv_buf(sock, i*6, 4)` 给每个 Socket 分配独立收发缓冲。按`docs/芯片手册/CH395F.md` §5.45（48 块 × 512B = 24KB）+ §9.2.8 最优分配：每 Socket 6 块 = 接收 4 块(2KB) + 发送 2 块(1KB)，`ch395f_set_tcp_mss(1024)`，恰好用尽 0~47 块、互不重叠。
3. MSS 选取依据 §9.2.8：接收缓冲(2KB) ≥ 2×MSS(1024) 满足建议、≥ MSS 满足必须；发送缓冲(1KB) ≤ 8KB 满足必须。MSS 取 1024 为 8-Socket 共享 24KB 时的最大值。
4. `net_init` 缓冲分配顺序遵循 Trap 01：先配数据 Socket，再配监听 Socket 0（本 Net 层 Socket 按需 open，故统一在 init 一次性配好）。UDP 路径 `net_socket()` 中对 Socket 4~7 的兜底重设也同步为同一布局。
5. PC 端 `tcp_server` 改为每连接一线程的并发回显（`--max-conn` 为并发计数），否则 Phase 7 全量连接会触发累计计数上限而拒掉 4~7（Trap 19）。
### 注意事项
- 4~7 的缓冲必须显式分配，否则其 CONNECT/RECV 中断不触发（Trap 01/02）。
- 上述布局**以手册 §5.45 的 48×512B 缓冲几何为准**，并已由 Phase 7 TC704（40/40 PASS）实测确认块 0~47 全部有效（此前文档中"32×1KB"记录有误）。Socket 4~7 分配与 8 路并发回显均验证通过。
- 上述布局**以`docs/芯片手册/CH395F.md` §5.45 的 48×512B 缓冲几何为准**，并已由 Phase 7 TC704（40/40 PASS）实测确认块 0~47 全部有效（此前文档中"32×1KB"记录有误）。Socket 4~7 分配与 8 路并发回显均验证通过。
- 多 Socket 模式下 TCP Server 单连接语义不变：Socket 0 监听且连接停留在本 Socket，Sockets 1~7 由应用当作独立 client 使用。
- `net_poll` 用 `GET_GLOB_INT_STATUS_ALL`（2 字节，支持 0~7）并遍历 0~7，Socket n 中断位即 `bit(n+4)`（Socket 0~3→bit4~7，Socket 4~7→bit8~11），原代码正确无需改动。
@@ -738,13 +738,13 @@ NET 层 TCP Client（阶段 7）`net_connect()` 返回 0，但 `net_poll()` 报
---
## Trap 24：MAC 写入顺序违反手册 §9.2.1（SET_MAC 必须在 INIT_CH395 之前）
## Trap 24：MAC 写入顺序违反`docs/芯片手册/CH395F.md` §9.2.1（SET_MAC 必须在 INIT_CH395 之前）
### 现象（静态审查发现；手册确证）
`net_init()` 原顺序为 `ch395f_init()`（CMD_INIT_CH395）→ `ch395f_set_mac_addr()`，与手册 §9.2.1 规定的初始化顺序**相反**。后果：INIT_CH395 已按 EEPROM 旧值加载 MAC，其后写入 EEPROM 的新 MAC 本次上电**不生效**（回落芯片内置/上次值，实际"滞后一次上电"）→ UI 配置的 MAC 与设备实际在线 MAC 不一致，设备在线身份错误、网口排查困难。本轮未做"UI 改 MAC + 重启"台架复现，结论由手册条文确证。
`net_init()` 原顺序为 `ch395f_init()`（CMD_INIT_CH395）→ `ch395f_set_mac_addr()`，与`docs/芯片手册/CH395F.md` §9.2.1 规定的初始化顺序**相反**。后果：INIT_CH395 已按 EEPROM 旧值加载 MAC，其后写入 EEPROM 的新 MAC 本次上电**不生效**（回落芯片内置/上次值，实际"滞后一次上电"）→ UI 配置的 MAC 与设备实际在线 MAC 不一致，设备在线身份错误、网口排查困难。本轮未做"UI 改 MAC + 重启"台架复现，结论由手册条文确证。
### 根因
手册 §9.2.1「初始化 CH395，必要操作」顺序为：
`docs/芯片手册/CH395F.md` §9.2.1「初始化 CH395，必要操作」顺序为：
① `SET_MAC_ADDR` → ② `SET_IP_ADDR` → ③ `SET_GWIP_ADDR` → ④ `SET_MASK_ADDR` → ⑤ `INIT_CH395`。
- §5.7：`SET_MAC_ADDR` 把 MAC **写入芯片内部 EEPROM**（约 30us）；
- §5.13：`INIT_CH395` **初始化 CH395 的 MAC、PHY 以及 TCP/IP 协议栈**（约 5ms）。
@@ -766,4 +766,92 @@ NET 层 TCP Client（阶段 7）`net_connect()` 返回 0，但 `net_poll()` 报
`Drivers/BSP/NET/net_socket.c`（`net_init` SET_MAC 顺序）、`Drivers/BSP/NET/net_socket.h`（`net_init` 注释）、`Drivers/BSP/CH395F/ch395f.c`（四个 SET 的限定条件注释）；`docs/网络/BSD_Socket_API_函数调用关系.md`（§4.1 / §7 顺序）。
### 发现时间
2026-10-04（静态审查项 P1-7；依据手册 §9.2.1 / §5.7 / §5.13 定案）。
2026-10-04（静态审查项 P1-7；依据`docs/芯片手册/CH395F.md` §9.2.1 / §5.7 / §5.13 定案）。
## Trap 25：FTP 数据连接三连故障——丢 CONNECT 中断 / accept 竞态自毁缓冲 / 背靠背小段毒化 TX（N-30，2026-10-11 定案并修复，回归 4 轮 11/11）
### 现象（生产 FTP 回归，多轮复现）
同一 FTP 会话内**第 2 次及以后**的数据连接（LIST/STOR/RETR 各一次）出现两类失败，两种面孔同一根因：
- **吞数据（SWALLOW）**：新数据连接建立成功（芯片 0x05/0x04 ESTABLISHED）、服务端 `net_send` 返回成功，客户端 20 s 收不到任何字节（无 RST、无 DISCONNECT，直到客户端放弃）；
- **425**：新数据连接被接受后 ~10-20 ms 内出现 DISCONNECT（`chip tcp=0x00`），服务端 accept 失败 → `425 Can't open data connection`。（⚠ 本条当时的解读"芯片自杀连接"**有误**，见文末"三次定案"——实为客户端发完数据后的**正常 FIN** + 我方 accept 竞态自毁缓冲。）
失败概率随**上一条数据连接的负载大小与间隔**变化（NAND 目录文件越多 LIST 越大越易触发），与提交历史无关——在 D20 基线 e5733b34 上以快速连发同样复现（D20 时代"11/11 通过"是慢速台架 + 干净目录的运气）。
### 定案实验（裸机芯片台架，剥离 OS/net/FTP）
实验分支 `n30-chip-bench`（worktree），`test/board/ch395f_reuse_bench.c` 在**内核启动前**直接调 `ch395f_*` 做受控矩阵：`{socket, close 后复开延迟, TX 长度, 关闭顺序}` 组合循环，每 50 ms 打印芯片两字节状态 + 中断寄存器；主机侧 `test/host/ch395f_reuse_host.py` 同步做纯 TCP 客户端。**OS/net/FTP 全部剥离后 bug 依旧复现** → 纯芯片操作时序问题，非上层逻辑、非芯片硬件缺陷。
关键现场（芯片日志）：
```
post-listen st=0x05/0x04 ← listen 返回成功，但 TCP 态停在旧连接的 ESTABLISHED（幽灵态）
unexpected int=0x10 while wait ← 只等来旧连接滞后的 DISCONNECT
no CONNECT within 10s ← 新连接的 CONNECT 中断永远没来（芯片状态却已是 0x04）
```
**芯片级规律**：CH395F 关闭连接后的拆链收尾窗口**变长且不可观测**——状态寄存器显示 CLOSED 持续 1 s 以上也不代表拆完（实测窗口可 >2 s 且时长不定）。窗口内重新 `open+listen`：
1. 新连接握手照常完成（状态寄存器 → ESTABLISHED）但 **CONNECT 中断被丢**（Trap 22 丢中断机制的窗口期形态）→ 事件驱动的 accept 永远等待 → 吞数据；
2. 或 listen 后状态直接假报 0x04（幽灵态），此时回读对端端口 = **旧连接端口**；
3. 或旧连接滞后的 DISCONNECT 打到新监听 → 触发 relisten 毁掉刚到的新连接 → 425。
### 已证伪的修复（全部经台架受控实验）
| 尝试 | 结果 |
|---|---|
| close 后固定沉降 100/300/800/2000/3000 ms | 仍挂（2 s 也挂过）——窗口变长，固定等待无保证 |
| Socket 轮换（sock3↔sock4 交替） | 仍挂——上一轮拆链尾巴跨 socket 毒化下一轮 |
| listen 后 close+重试 / 耐心等幽灵消退 | 持平对照组，无效 |
| 收发缓冲重分配（clear_recv_buf + set_*_buf） | 无效 |
| close 前 200 ms TX 排空延时 | 无效 |
| 禁用对账 tick（验证因果） | 仍挂——对账不是元凶 |
### 有效修复（台架修复组 15/15，机制触发 5 次全部救回）
**双信源原则：中断只是快路径，状态寄存器才是真相。** 等连接时不能只等中断：
1. **accept 路径内联探针**（`net_lost_connect_probe`，`net_accept_locked` 每 100 ms 轮询挂探针）：芯片状态已 ESTABLISHED 而 CONNECT 中断未到 → 连续 2 轮去抖后补做 accept（复用 `handle_connect_event` 簿记）。
2. **幽灵态甄别**：补 accept 前回读对端端口（`GET_REMOTE_IPP`），**端口 = 上一条连接端口（`last_peer_port`）→ 幽灵，不 accept**——否则会把数据发给已死的旧连接（这正是生产 LIST#4"accept 成功但数据被吞"的直接成因：对账②曾把幽灵连接补 accept 了）。
3. **对账②同步加幽灵甄别**（`net_reconcile_tick` 类型②分支同样比对 `last_peer_port`）。
4. `last_peer_port` 登记点：`handle_disconnect_event` / `handle_timeout_event` / `net_relisten_try`（清零 remote_port 前转登）/ `net_close_locked`（跨 memset 保留——幽灵属芯片 Socket 级，与 fd 复用无关）/ NET_MSG_FIX 陈旧 ESTABLISHED 修复路径。
### 与 Trap 22 的关系
Trap 22 的周期对账（200ms 节拍 + 400ms 去抖 + 1s 冷却）设计目标是"自愈兜底"，对常驻监听器有效；但 FTP 数据通道是"活 1 秒就死"的短命监听器，且对账②**无幽灵甄别**——它既救不全（冷却期内 accept 已超时）又反过来帮凶（把幽灵补 accept）。Trap 25 把"看状态补 accept"内联进 accept 热路径（短去抖、无冷却）并补上端口甄别，对账②保留为兜底网。
### 对应文件
`Drivers/BSP/NET/net_socket.c`（`net_lost_connect_probe` / `net_accept_locked`（含 closed-with-data accept）/ `net_reconcile_tick`② / `last_peer_port` 各登记点）、`Drivers/BSP/NET/net_types.h`（`last_peer_port` / `lost_conn_seen` 字段）、`Drivers/BSP/NET/lftpd/lftpd.c`（`send_list`/`send_nlst` 批量发送）；台架工具 `test/board/ch395f_reuse_bench.{c,h}` + `test/host/ch395f_reuse_host.py`（实验分支 `n30-chip-bench` 注册编译，主分支只存档不注册）。
### 验证（台架层）
`ch395f_reuse_bench` 修复组（丢中断捕获自 accept）15/15，机制触发 5 次全部救回（对照同表 4/15 挂）。⚠ 生产回归当时未达 11/11——生产主导模式与台架不同，见下两节。
### 三次定案：所谓"kill 模式"是寄存器状态误读（2026-10-11 当日终案，双向验证）
第二轮验证（仅双信源探针修复，4 轮：1/11、5/11、2/11、2/11）暴露 STOR #2 仍 100% 失败，当时解读为"芯片在 accept 后 10-20 ms 杀连接"。后经**手册条文 + 网络资料双向核对**推翻：
**寄存器读数本身全部正确**（`GET_SOCKET_STATUS_SN` §5.22：`05H=SOCKET_OPEN/00H=SOCKET_CLOSED`；第二字节 TCP 态 `00H=CLOSED/04H=ESTABLISHED`，与 WCH 官方数据手册表 5-8/5-9 一致；`GET_RECV_LEN_SN` §5.33 低字节在前，驱动实现一致）。**错在对 DISCONNECT 事件语义的解读**：
1. `net_init` 的 `ch395f_set_fun_para(0x09)` 置 **FUN_PARA_FLAG_SOCKET_CLOSE=1**（§5.52 ②）：产生 DISCONNECT/TIMEOUT 后芯片**不关 Socket、不清缓冲**，就是留给单片机把残留数据读出后再关 Socket。
2. 判别探针现场：`kill-check recv_len=1027 re-read st=0x05/0x00`——Socket 仍 OPEN、TCP 已 CLOSED、**RX 缓冲 1027 字节 = STOR 载荷一个不少全在**。这是芯片按 §5.52 规格**保留现场**，不是杀连接。
3. 那个 DISCONNECT 是**客户端的正常 FIN**：Python ftplib `storbinary` 语义 = `sendall` 发完立即关数据连接，然后回控制通道等 226——标准 FTP 行为。局域网小文件下"连接→发完→关闭"在 ~5 ms 内完成。
**425 真根因（竞态 + 自毁缓冲）**：客户端 5 ms 内完成发送并关闭；`cmd_stor` 的 accept RPC 赶到 net 层时 MCU 态已是 CLOSED；旧 `net_accept_locked` 把 CLOSED 一律当"无连接" → `net_relisten_try`（close+open **清空芯片 RX 缓冲**）→ 1027 字节被**我方亲手销毁** → WOULDBLOCK → lftpd 判"数据套接字已关" → 425。芯片全程无辜（此模式）。
**有效修复（已落地，`net_accept_locked` CLOSED 分支）**：CLOSED + auto_relisten + **芯片 RX 缓冲有数据**（`GET_RECV_LEN_SN`>0）→ 接受这条"已关但可读"连接（日志 `closed-with-data accept (drain pending)`），应用经 `net_recv_locked` 快路径（无状态门槛）排空，排空后 EOF 自然触发 relisten——完全对齐 §5.52 ②"读出残留数据后再关闭"的芯片契约。**验证：修复后 4 轮回归 STOR #2 从 4/4 失败 → 4/4 通过**（7/11、6/11、9/11、5/11，失败项中已无 STOR）。
**连带修正**：台架 mode0（主机先关）观察到的"accept 后 10-20 ms DISCONNECT"大概率同为误读——那是主机收完数据自己关的。"拆链窗口杀连接"理论对生产 425 不成立；台架**丢 CONNECT 中断模式**（主机侧 got=0 + 芯片 0x04 + 无中断，主机端独立证据）仍然成立，双信源探针修复保留。
**当时的遗留**：LIST #4/#7 超时（服务端 `net_send` 目录、客户端 20 s 收 0 字节、无 DISCONNECT）——发送方向的真问题，与上述 425 机制不同——已由下节"四次定案"解决。
### 四次定案：LIST 吞包 = 背靠背小段写毒化芯片 TX（2026-10-11 终案，修复后 8/8 通过）
探针定位过程（全部生产固件 + 临时探针，一轮复现）：
1. PASV→accept 间隔 2 s（`net_listen_locked` open 重试在跑）→ 曾疑"listen 撞拆链窗口"；
2. accept 正常、CONNECT 正常、发送后中断位 `0x03`（SENBUF_FREE+SEND_OK）——**芯片自认发送成功**；
3. `GET_REMOTE_IPP` 对端 IP:port 完全正确（排除对端混淆）；
4. **Socket 轮换**（服务端先关后 4 s 冷却、数据连接轮转 sock3~7）：**证伪**——LIST 换到全新 sock5 仍 100% 挂（芯片行为与失败前完全一致）；
5. **决定性对照**：同一目录同一载荷，LIST #1（会话首连，FAT 冷、readdir 慢、行间天然间隔大）通过；LIST #4/#7（FAT 热、每行一个 `net_send` 背靠背小段）必挂。
**定案**：`send_list`/`send_nlst` 每行一次 `net_send`（~60 B 小段、间隔仅 ms 级）——CH395F 对同一连接的**背靠背多段小写入**会把 TX 整条连接毒化（芯片报 SEND_OK 但对端协议栈全部丢弃，无 RST 无 DISCONNECT）。`net_send_locked` 的逐块协议（等 SENBUF_FREE 再写下一块）本身合规（§5.45），但芯片对该模式的内部处理不可靠；RETR 的 1 KB 满块连发不受影响（实测通过）。
**修复（`lftpd.c`）**：`send_list`/`send_nlst` 整份目录**一次性批量发送**（static 1536 B 缓冲，snprintf 累积 + 单次 `lftpd_inet_write`；溢出截断判 -1→550）。注意 `lftpd_inet_write` 成功返回**字节数**非 0（首版误按 0=成功判 → 全 550，已纠）。
**验证**：修复后 ftp_regression 连跑 **4 轮 11/11**（终版：批量发送 + closed-with-data accept + 丢中断探针 + 幽灵甄别，无轮换无探针）+ `ftp_auth_bench.py` **13/13** + `@test` 启动标记 PASS；此前同条件 LIST #4/#7 为 100% 失败、STOR #2 曾 100% 425。轮换冷却机制随证伪**已撤**（不留未证明的复杂度；其 5 轮 11/11 一并存档备查）。
**教训（Trap 25 总纲）**：本轮先后误读三次——把客户端正常 FIN 读成"芯片杀连接"、把 open 重试读成"拆链窗口"、把芯片假 SEND_OK 读成"数据已上线"。铁律：**CH395F 的"成功"（中断位/状态码）只代表芯片本地动作完成，不代表对端收到；判定必须回到对端可见证据（主机侧收发）+ 手册语义（FUN_PARA §5.52、状态码 §5.22）**。
**顺带发现的疑点（存疑，暂不动）**：`set_fun_para(0x09)` 的 bit0——§5.52 表明确写 **bit0 保留、必须为 0**，而 `net_init` 注释声称"bit0=1 多 Socket 模式"（手册与网络资料均无此说法，CH395 的 8 Socket 是芯片原生能力，单/多 Socket 之分在手册中只关联 SCS0 引脚硬件形态）。现固件 bit0=1 下 sock1/2/3 多路并行正常 → 该位大概率被芯片忽略。**本轮不改**（若真为多 Socket 使能，改 0x08 会毁掉全部 1~7 号 Socket）；后续单独台架验证"0x08 下多 Socket 是否仍正常"再定。
### 发现时间
2026-10-11（登记簿 N-30；裸机芯片台架定案实验见本节，实验分支 `n30-chip-bench`）。