 wandering1
|
33405a57b5
|
docs(N34)+test: E13 僵尸会话根因坐实；Phase 11 判据修正+一次性报告
E13（实验方案.md 新增 + E8/E11/E12 口径修正）：
- 风暴态根因=僵尸会话，非芯片残渣：PC 网卡禁用/链路断开时
Windows 直接丢弃 socket 不发 FIN/RST → 芯片侧 ESTABLISHED 僵尸
→ 单连接监听被占（:21 拒连）→ 下一 PASV 重监听与僵尸竞态
（accept 为垂死僵尸开枪 20ms 后 DISCONNECT）→ lftpd 5s 窗空转
→ 425；每失败轮再生僵尸 → 自续数分钟
- "残渣跨烧录存活/需断电冷启动"口径作废：板上 CH395F RSTI 接
MCU NRST（V0.0 网表 :174），每次烧录即芯片硬件复位；"存活"是
锤击再生错觉。正确控制=下一臂前静置 ≥90s 清僵尸窗
- 自愈链端到端验证：TIMEOUT(在途 TX ≈30s)/keepalive(空闲 60/5/3)
→ pump → relisten → 端口恢复；E11 产品路径验证 17s 判死 PASS
- 4 元组复用假设被否（pasv_probe.py：PASV 端口递增、PC 源端口随机）
- e02_probe listener=FAIL 重解读：探针挂起 socket 未关（PC 内核
代 ACK keepalive）→ 拒连是单连接正确行为；真缺口=应用无法主动
拆会话 → 阶段 2 sock_reset 职责
Phase 11 测试修复（net_test_task.c，实跑暴露）：
- 判据 >=60000ms 是按手册公式写的，实测判死 18~31s 会在正确固件
上假 FAIL → 改有界窗 10s~120s（下限防误杀存活空闲会话，上限
防判死缺位）
- 报告后不释放 phase_active → 对已死连接 10ms 节奏刷 594 条假
FAIL → phase11_run 返回完成态，主循环释放等新连接再测
- 复跑两轮验证：30137ms 单次 PASS → 自动等新连接 → 二轮 accept 正常
- Test_Guide TC-NET-1101 判据/耗时同步；ch395f_test.h Phase 14
共存安全性注释（有整体超时不永久挡 accept）
工具：test/host/pasv_probe.py（每轮打印 PASV 端口+PC 源端口+结果）
|
2026-10-13 11:23:40 +08:00 |
|
|
wandering1
|
13a4a40a14
|
feat(net): 服务器侧 KeepAlive 转正（§5.56，E11）+ Phase 11 重开回归
E11（d96113b）证据链："链路在、对端静默"注入下生产参数 60/5/3 实测
判死 ≈30s → TIM_OUT → QUARANTINE → pump 重建；静默但存活对端不误杀。
handle_connect_event LISTENING 分支按手册规定位置开启；反汇编确认
编译器把两分支尾部合并（LISTENING 跳入含 keepalive+fire_event 的公共
尾部，hex 全片仅该分支偏移 1 行差异，Code 尺寸不变属填充巧合）。
Phase 11 重开时发现其拉入 32KB s_rx_buf 超产品 RAM 余量（L6406E 链接
失败）→ 改专用 64B 探针缓冲（本 Phase 仅 64B 探针读，门控注释已留
"勿加回"警示），套件恢复 0 错 0 警；TC-NET-1101 步骤同步死对端注入法
（禁用网卡；Windows 防火墙规则对已建立连接无效，E11 实证）。
验证：产品/套件双构建 0 错 0 警 + 反汇编确认调用落地；台架确认
（:7003 静默对端判死 + Phase 11 实跑）待设备冷启动断电重上电后补做。
|
2026-10-13 09:25:06 +08:00 |
|
|
wandering1
|
d758d5cd7b
|
docs+net: FUN_PARA 定案 0x08——bit0 保留位证伪，Trap18 定案更正 + N-31
CH395F FUN_PARA 的 bit0 之争定案：取 0x08（bit3 SOCKET_CLOSE=1，bit0=0）。
证据（一手，按强度）：
- 官方手册 V2.2/V2.3 与旧版 V1C/V1E/2020 版 §5.52 位表：bit0 一律
「保留,必须为0」，任何版本都不存在「bit0=多 Socket」这一行。
- 官方 SDK CH395INC.H:349-353 位宏只有 bit1/3/4/7/8，无 bit0 宏。
- 官方例程直接反例：EXAM5_TCP_Server 传 0x02（bit0=0）却给 Socket 0~7
全部配缓冲；EXAM11_FTPClient 直接传 0x08；全 EVT 包无一处 0x09。
- 手册命令章前言：8 Socket 是芯片原生能力，靠 _SN 索引寻址；§5.45
真正的门槛是缓冲分配（Socket 个数 >4 须重分配缓冲）。
- 概念讹传源是 bit1 FUN_PARA_FLAG_TCP_SERVER（服务器多连接，§9.2.6）。
- 互联网检索无任何出处称 bit0 为单/多 Socket 模式。
Trap 18 的「bit0 决定 Socket 数量」是推论而非实测：无日志、无 TC 号，
且当年 Socket 1~7 未显式配缓冲（Trap 01/02 混淆因子未排除）；TC704
40/40 与结论出自同一提交，属自证，不构成 0x08 的对照。
改动：
- net_socket.c：0x09→0x08（原为未提交改动，现已过编译门禁）+ 版本留痕
- ch395f_reuse_bench.c：0x09→0x08，与生产 net_init 同构
- net_test_task.c：TC704 注释纠正（Socket 可用性不依赖 FUN_PARA）
- Trap 18 新增「定案更正」完整证据链；Trap 25 疑点改判为定案
- Test_Guide / 产品需求 / 架构总览 / BSD 调用关系：0x09→0x08 改口径
- 待处理内容.md 登记 N-31：0x08 下多 Socket 台架复测（TC704 降并发
≤5 + FTP 回归），补 Trap 25 销项时漏登记的尾巴
验证：@build 0 错误 0 警告；check_doc_links --all 通过；无 U+FFFD。
|
2026-10-11 20:05:22 +08:00 |
|
|
wandering1
|
22559365b9
|
整理 App 与 test 目录：按职责分子目录并同步全库引用
|
2026-09-26 12:52:39 +08:00 |
|