wandering1
9a45be1700
docs(net-audit): B1 服务器侧 KeepAlive 前提被实测推翻，撤回改动并记台架注入陷阱
B1 原判"产品路径从未启用 Socket KeepAlive → 静默断开无人知晓"（§5.56
要求 TCP 服务器在产生 SINT_STAT_CONNECT 后开启，产品三服务全是
Server，60s/5s/3 参数空转）。本轮按 §5.56 在 LISTENING→ESTABLISHED
分支补了 ch395f_set_keepalive_enable() 并上板做定案实验，结果推翻前提。
实测：连接静置时禁用 PC 网卡（真·静默死亡），芯片 +2 s 即报
"[ERR][NET] sock0 TIMEOUT" → 本层 relisten quarantine 释放重开监听。
2 s 只能是重传（§5.17 本仓 8×200 ms = 1.6 s 量级），与 KeepAlive 无
关——IDLE 最短 60 s、芯片默认也要 20 s。链路层失效本就被快速覆盖，
故依 Trap 25 铁律「不留未证明的复杂度」撤回该改动，只在代码内留注释
记录（含未覆盖场景与注入难点），不保留无证据的动作。
另一半天真：设备 2 s 就重开监听，PC 侧那条 socket 却继续"自认存活"
直到 4 分钟后自行 close（Python 对死链路 close() 不报错）。不对称恢复
才是现场隐患——客户端下次写会吃到 §5.29 的 RESET；单靠设备侧开
KeepAlive 只解决设备这一半。
新增「台架注入陷阱（2026-10-12）」四条（本轮踩到的，全部实测）：
1. Windows 出站防火墙规则不能模拟"对端静默死亡"——WFP 对已建立的流
有状态缓存，中途加 Block 不影响既有连接；实测静置+阻断 250 s 芯片
毫无反应，看着像"KeepAlive 不生效"，实则 ACK 一直正常往返。
2. 该规则还会吃掉本机后发的 FIN → 设备留下幽灵 ESTABLISHED，之后新
连接被 §5.29"向试图连接的远端发送 TCP RESET"直接 RST，表现为"端口
拒连"，极易误判成设备故障（实为自伤，撤规则后自愈）。
3. 真正掐断链路用 Disable-NetAdapter；本机该 cmdlet 只有 -Name /
-InterfaceDescription，没有 -InterfaceIndex/-ifIndex（第一次写错
导致那轮网卡根本没关）。网卡名是中文，用
(Get-NetAdapter -InterfaceIndex 19).Name 取值再传，避免命令行写中文；
禁用/恢复必须写在 try/finally 里。
4. 仍未覆盖："链路仍在、对端静默"（NAT 会话过期、中间节点黑洞）才是
服务器侧 KeepAlive 唯一可能的价值场景，本机无安全注入手段（静态
ARP 黑洞会被交换机泛洪兜底、删 IP 会连带拆掉本机连接）——未证实，
故不保留改动。
判读教训（与 Trap 25 同源）：看到 TIMEOUT 先算时序再归因，2 s 与 60 s
一眼可分；否则会把重传超时误记成"KeepAlive 生效"，把相关性当因果。
验证：构建 0 错 0 警、Code=196912（与 afb0bfd 一致，说明撤回后二进制
回到已提交状态）；doc-links EXIT=0、Trap_Records 无 U+FFFD 无 BOM；
@test 闭环 PASS（回读无差异 + forbidden 三项与 [ERR] 全缺席 + 594 ms）。
2026-10-12 07:49:58 +08:00
..
2026-10-12 07:49:58 +08:00
2026-10-10 01:05:15 +08:00
2026-10-10 15:24:02 +08:00