From 17e2512f6a430525713b274e2990fff52beb8db6 Mon Sep 17 00:00:00 2001 From: agent Date: Tue, 28 Jul 2026 14:13:57 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20=E6=89=93=E7=BB=93=E2=80=94=E2=80=94?= =?UTF-8?q?=E4=BF=AE=E6=AD=A3=20usbip=20=E6=A0=B9=E5=9B=A0=E7=BB=93?= =?UTF-8?q?=E8=AE=BA=EF=BC=88=E5=A4=A7MTU=20GATT=20=E6=B5=81=E9=87=8F?= =?UTF-8?q?=E8=A7=A6=E5=8F=91=EF=BC=89=EF=BC=8Cbridge=20=E6=9E=B6=E6=9E=84?= =?UTF-8?q?=E7=AB=8B=E9=A1=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- DECISIONS.md | 2 ++ PROGRESS.md | 16 ++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/DECISIONS.md b/DECISIONS.md index 448d228..d8606b5 100644 --- a/DECISIONS.md +++ b/DECISIONS.md @@ -10,3 +10,5 @@ | 2026-07-24 | 固件头格式确认（magic 'pQ'/flags 0x01AA/长度/CRC32(body)/64B 头/0x20 填充 0x00） | 以 zlib.crc32 反推验证 CRC 字段 = body 的 CRC32，重打包字节级往返一致 | fw_pack 可生成与原镜像格式一致的文件，是固件可控（G4）的基础 | | 2026-07-24 | 中英混排 0.5 单位的倒计时前缀在 CLI 拒绝 | JS `'0'+charCount` 遇 3.5 生成非法 hex "03.5" | 属于上游 bug 路径，CLI 显式报错优于发送畸形帧 | | 2026-07-28 | 真机测试阻塞定责：USB/IP 透传链路（hci0=vhci_hcd，源 192.168.61.35:3240 Intel AX200）在 BLE 连接数据窗口 ~3s 后硬停 | btmon 两次复现：连接建立成功→MTU 交换成功（设备 RX MTU 512）→服务发现推进→~19 个 ACL 包后悬崖式断流→Disconnect 0x08；对照设备（小米温湿度计 RSSI -27）同样失败 | 排除设备与协议软件问题（扫描/连接建立/ATT 初期均正常）；属 usbip-host 中断端点饥饿类故障；需在 usbip 源机原生运行或修 usbip，详见 PROGRESS.md 阻塞节 | +| 2026-07-28 | **结论修正**：根因 = **大 MTU GATT 流量触发链路断流**（非此前判断的"中断端点饥饿"），具体归因于 usbipd-win/VBoxUSB/VHCI/AX200 固件链中某一环，无法唯一归因 | 熠管家在 Windows 侧排查：76B 响应完整到达 guest、下一请求已被 AX200 接收；**ATT MTU=23 时全部服务+22 个 characteristic 发现成功、无监督超时**；usbipd-win 5.3.0 + Ubuntu 6.8.0-136 均为最新 | 不能全局降 MTU（EPD 图像帧 244B > MTU23），故转向 bridge 架构：BLE 在 host-win 原生执行，guest 经 RPC 调用（见下条） | +| 2026-07-28 | 引入 **bridge 能力**：host-win 原生跑 bleak(WinRT) 并以 JSONL/TCP 暴露 RPC，ubuntu-openclaw 的 ppclock 经 BridgeTransport 远程调用 | usbip 链路无法承载大 MTU GATT；Windows 原生 BLE 无此问题；NFS 仓库两边可达 | 交付：tools/bridge_server.py（单文件服务端）+ src/ppclock/bridge.py（与 BLETransport 同接口）+ CLI `--via bridge://host:port` / `PPCLOCK_VIA` 环境变量 | diff --git a/PROGRESS.md b/PROGRESS.md index 50d1c80..86c3fd3 100644 --- a/PROGRESS.md +++ b/PROGRESS.md @@ -75,6 +75,22 @@ **已保留的 guest 侧改善**：`/sys/bus/usb/devices/1-1/power/control=on`（重启后需重设；可写 udev 规则固化，见 README）。 +### 2026-07-28：排查打结（结论修正）+ bridge 架构立项 + +**熠管家 Windows 侧排查结论（采纳，替代此前归因）**： +- 192.168.61.35 = Windows host-win/banyWinServer（usbipd-win 5.3.0），非 Linux +- 76B 响应完整到达 guest、下一请求已被 AX200 接收 → 非"中断端点卡住" +- **ATT MTU=23 时全部服务 + 22 个 characteristic 发现成功、无监督超时** → 定性为"大 MTU GATT 流量触发断流"，具体环节（usbipd/VBoxUSB/VHCI/AX200 固件）无法唯一归因 +- 不能全局降 MTU（EPD 图像帧 244B），运行态已恢复 + +**打结**：本机 usbip 路径不可用于大帧 GATT，放弃修复，转 bridge 架构。 + +**bridge 立项**（见 DECISIONS 2026-07-28 第 3 条）： +- `tools/bridge_server.py`：host-win 原生运行（Python+bleak/WinRT），JSONL/TCP RPC +- `src/ppclock/bridge.py`：BridgeTransport，与 BLETransport 同接口，全部 CLI 命令透明可用 +- 调用方式：`ppclock --via bridge://192.168.61.35:8971 ...` 或 `PPCLOCK_VIA=bridge://...` +- field_test.py 经 `PPCLOCK_VIA` 环境变量继承，无需改动 + ### 会话时间线 - 08:14 目标设定（治理+规划+执行）