forked from zbw/yiliao2026
docs: record DDS link recovery and live traffic proof
This commit is contained in:
@@ -1227,7 +1227,111 @@ rmdir --ignore-fail-on-non-empty /home/hikos/Yiliao2026/config/dds
|
|||||||
- WSL 当前分支为 `zbw`。保留了 `.vscode/browse.vc.db*`、`.codex`、`resource/`、`src/navigation/`、`src/obstacle_scanner/`、`src/origincar_birdseye/`、`src/third_party/`、`tf_bag/` 等已有 dirty files，未暂存、未清理、未纳入本任务提交。
|
- WSL 当前分支为 `zbw`。保留了 `.vscode/browse.vc.db*`、`.codex`、`resource/`、`src/navigation/`、`src/obstacle_scanner/`、`src/origincar_birdseye/`、`src/third_party/`、`tf_bag/` 等已有 dirty files，未暂存、未清理、未纳入本任务提交。
|
||||||
- 未修改 `.bashrc`、路由表、防火墙、网卡 metric、Nav2 参数、ROS package、SSH 或 VS Code 配置；配置仅在终端中显式 `source` 后生效。
|
- 未修改 `.bashrc`、路由表、防火墙、网卡 metric、Nav2 参数、ROS package、SSH 或 VS Code 配置；配置仅在终端中显式 `source` 后生效。
|
||||||
|
|
||||||
WSL 最终 XML 完整内容：
|
### 2026-07-23 18:51 后续卡顿诊断与恢复计划
|
||||||
|
|
||||||
|
#### 只读诊断证据
|
||||||
|
|
||||||
|
- 重启前 `ip route get 192.168.10.151 from 192.168.10.164` 返回 `dev wlx200db0c3fca5 table 164`；活动 Nav2 participant 的专用 UDP socket 绑定 `192.168.10.164`。因此已加载专用 profile 的 DDS 当时确实走 `.164`。
|
||||||
|
- 同一启动周期累计计数显示：`.210` 的 `wlan0` 发送约 `11.58 GB / 3611 万包`，`.164` 网卡发送约 `64.5 MB / 22 万包`。该数量差异表明 `.210` 另有非专用 DDS 环境的流量。
|
||||||
|
- Windows 对 `.210` 的 20 次 ping 为平均 `4 ms`、最大 `55 ms`；`.164` 为平均 `2 ms`、最大 `5 ms`。
|
||||||
|
- 18:52:55 启动的两个只读 `tcpdump` 均由 `timeout 8` 控制，并在 18:53:03 正常关闭 sudo session；没有遗留 tcpdump。随后 RDK 网络失联并在 18:57:03 重新启动，上一启动日志末尾没有正常 shutdown 记录，因此只能确认发生了非正常重启，不能从现有日志证明触发源。
|
||||||
|
- 重启后 `wlx200db0c3fca5` 为 `NO-CARRIER`，没有 `.164` 地址、table 164 或 source rule；`openwrt_5G` 当前扫描不可见。
|
||||||
|
- `.210` 管理网卡改连 `kskbl_2.4G`，协商 TX 约 `52 Mbit/s`。一个未设置 `FASTRTPS_DEFAULT_PROFILES_FILE` 的 ROS 2 daemon 绑定 `192.168.10.210`，说明未显式 source 专用脚本的 ROS CLI 会绕过 `.164` 配置。
|
||||||
|
|
||||||
|
#### 方案与实施顺序
|
||||||
|
|
||||||
|
采用回退连接方案：保留 `/etc/NetworkManager/dispatcher.d/90-wlx164-policy-route`、`.210` 管理连接和两个 Fast DDS XML 不变；克隆现有 `kskbl_2.4G` 凭据为只绑定 `wlx200db0c3fca5` 的回退 profile。原 `openwrt_5G 1` 保持为 `.164` 的 5G profile，并将其自动连接优先级设为 `100`；回退 profile 优先级为 `50`。
|
||||||
|
|
||||||
|
执行步骤：
|
||||||
|
|
||||||
|
1. RED 基线：确认 `.164` 不存在、`use_rdk_dds_164.sh` 返回失败、错误 ROS daemon 的环境中没有 Fast DDS profile 且 socket 位于 `.210`。
|
||||||
|
2. 创建 `kskbl_2.4G-rdk164`，绑定 `wlx200db0c3fca5` 并试连接。只有 DHCP 返回 `192.168.10.164` 才继续；否则立即断开并删除该 profile。
|
||||||
|
3. 确认现有 dispatcher 自动恢复 `from 192.168.10.164/32 lookup 164`，且 `.164 -> .151` 走 USB 网卡；不直接编辑路由表、dispatcher、网卡 metric 或防火墙。
|
||||||
|
4. 停止错误环境创建的 ROS 2 daemon，从专用 DDS 环境启动新的 daemon，检查其环境变量与 UDP socket。
|
||||||
|
5. 使用双向一次性 ROS 2 消息、短时只计数抓包和 ping 验证 `.164` 承载 DDS、`.210` 没有同一批 DDS 包且 SSH 保持可用。
|
||||||
|
6. 将实际 profile UUID、命令、结果、Git 状态和残留进程检查追加到本节，只提交本 Markdown。
|
||||||
|
|
||||||
|
精确回滚：
|
||||||
|
|
||||||
|
```bash
|
||||||
|
nmcli connection down 'kskbl_2.4G-rdk164' 2>/dev/null || true
|
||||||
|
nmcli connection delete 'kskbl_2.4G-rdk164'
|
||||||
|
nmcli connection modify 'openwrt_5G 1' connection.autoconnect-priority 0
|
||||||
|
```
|
||||||
|
|
||||||
|
上述回滚只删除本次新增的回退 profile，并把既有 `openwrt_5G 1` 优先级恢复为实施前的 `0`；不得删除 `kskbl_2.4G`、`openwrt_5G 1`、策略路由脚本或 DDS 文件。
|
||||||
|
|
||||||
|
#### 后续恢复实施结果
|
||||||
|
|
||||||
|
- RDK 非正常重启后，`openwrt_5G` 扫描不可见，既有 `.164` profile 无法连接；`wlx200db0c3fca5` 没有地址，专用 DDS 脚本按设计返回失败。
|
||||||
|
- 新增 NetworkManager 回退连接：
|
||||||
|
- 名称：`kskbl_2.4G-rdk164`
|
||||||
|
- UUID：`98eb5d04-3bf5-49a2-96e7-4ec44171154f`
|
||||||
|
- 绑定接口：`wlx200db0c3fca5`
|
||||||
|
- 自动连接优先级：`50`
|
||||||
|
- DHCP 实际地址：`192.168.10.164/24`
|
||||||
|
- 既有 `openwrt_5G 1` UUID `9e4f4ea7-f087-4369-8faf-fa3d0faa9839` 继续绑定 USB 网卡，自动连接优先级由 `0` 改为 `100`，保持 5G 为下次启动时的首选。
|
||||||
|
- 既有 `/etc/NetworkManager/dispatcher.d/90-wlx164-policy-route` 未修改；回退连接成功后自动恢复：
|
||||||
|
|
||||||
|
```text
|
||||||
|
1000: from 192.168.10.164 lookup 164
|
||||||
|
192.168.10.173 from 192.168.10.164 dev wlx200db0c3fca5 table 164
|
||||||
|
```
|
||||||
|
|
||||||
|
- WSL/Windows 有线 LAN 的 DHCP 地址在网络重启后变为 `192.168.10.173`。仅在 WSL 内临时添加 `.151` 时，WSL 能发出但 RDK 无法反向 ARP；该临时地址随后已删除。
|
||||||
|
- 尝试用 Windows `New-NetIPAddress` 添加持久 `.151` 辅助地址时系统返回 `Access is denied`，没有产生 Windows 地址或路由修改。
|
||||||
|
- 因 `.173` 是当前真实可双向访问的 LAN 地址，最终将 WSL Fast DDS 本地地址和 RDK initial peer 从 `.151` 调整为 `.173`：
|
||||||
|
- RDK `/home/sunrise/yiliao_ws/config/dds/fastdds_rdk_164.xml`：仅把远端 peer `192.168.10.151` 改为 `192.168.10.173`。
|
||||||
|
- WSL XML 从 `fastdds_wsl_151.xml` 重命名为 `fastdds_wsl_173.xml`；transport/profile ID 改为 `wsl_udp_173` / `wsl_dds_173`，本地白名单与本机 peer 改为 `.173`，对端仍为 `.164`。
|
||||||
|
- WSL `use_wsl_dds_164_link.sh` 改为检查 `.173` 并加载 `fastdds_wsl_173.xml`。
|
||||||
|
- 新文件校验：
|
||||||
|
- RDK XML：`0644 sunrise:sunrise`，SHA-256 `41c2fcac3c23218c40c3d4cf4273504f8233296e5db6ac44c3bc120c5d989dd1`
|
||||||
|
- RDK 脚本未变：SHA-256 `5b40b2d3c61bd9d7eedfdb11ef1bb43dd60b3cdbb67ddcb1e2da01ab79996059`
|
||||||
|
- WSL XML：`0644 hikos:hikos`，SHA-256 `fa95118ced19bb0888789c8a0a59cbee1db2a01b00d3592a31b4bd9214ef7b4a`
|
||||||
|
- WSL 脚本：`0755 hikos:hikos`，SHA-256 `85a1390cbda47fed4f42c01210067a575775b79c267def83d24abdde0f232543`
|
||||||
|
- Git 提交：RDK XML `87f562d`；WSL XML/脚本 `c383338`。两个提交均只包含上述明确路径。
|
||||||
|
|
||||||
|
#### daemon 与运行中节点恢复
|
||||||
|
|
||||||
|
- 重启后发现 Domain 22 的 ROS 2 daemon 没有 Fast DDS profile，UDP socket 位于 `.210`。普通 `ros2 daemon stop` 和 `SIGTERM` 均未使该孤儿进程退出；在严格核对命令行后仅对该 daemon 使用 `SIGKILL`。
|
||||||
|
- 新 RDK Domain 22 daemon 从专用环境启动，环境包含两个 Fast DDS profile 变量，UDP socket 全部位于 `.164`。
|
||||||
|
- WSL 旧 daemon 同样绑定已失效 `.151`，按相同方式清理后从 `.173` 环境重启，UDP socket 全部位于 `.173`。
|
||||||
|
- WSL 原有 `origincar_birdseye offline_validation.launch.py` 的父进程没有 DDS profile，两个子节点仍绑定 `.151`。对明确 PID/命令行发送 `SIGINT` 正常停止后，用原命令在 `.173` 专用环境重启；`synthetic_camera_node` 与 `birdseye_node` 的 socket 均位于 `.173`。
|
||||||
|
- `.210` 仍有一个 `ROS_DOMAIN_ID=23` 的独立 daemon；它不属于本任务的 Domain 22，未终止、未修改。
|
||||||
|
|
||||||
|
#### 最终数据路径与延迟证据
|
||||||
|
|
||||||
|
- 双向一次性 ROS 2 消息通过：WSL 收到 `rdk_to_wsl_via_164`，RDK 收到 `wsl_to_rdk_via_164`。
|
||||||
|
- 在 RDK 从专用环境订阅 WSL `/image` 8 秒，第一次接口增量：
|
||||||
|
- `.164` RX `88,225,838` bytes，TX `345,016` bytes
|
||||||
|
- `.210` RX `2,042` bytes，TX `1,092` bytes
|
||||||
|
- 第二次同样负载：
|
||||||
|
- `.164` RX `90,334,970` bytes，TX `346,092` bytes
|
||||||
|
- `.210` RX `1,194` bytes，TX `1,092` bytes
|
||||||
|
- 结论：这两批约 84–86 MiB 的图像 DDS 数据经过 `.164`，没有经过 `.210`。
|
||||||
|
- 无负载时 `.210` 的 20 次 ping 为 `0%` 丢包、平均 `2 ms`、最大 `8 ms`。约 90 MB/8 秒图像负载期间，15 次 ping 仍为 `0%` 丢包、平均 `5 ms`、最大 `52 ms`。
|
||||||
|
- 剩余延迟尖峰不是 IP/DDS 泄漏：当前 `.164` 回退网卡与 `.210` 管理网卡都连接同一个 `kskbl_2.4G` AP，共享 2.4 GHz 空口。只有 `openwrt_5G` 恢复可见并由优先级 `100` 的 profile 在启动时选中，或使用独立有线/5G 链路，才能进一步消除射频竞争。
|
||||||
|
|
||||||
|
#### 后续配置精确回滚
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# RDK：撤销 peer 地址提交，并删除本次新增回退连接。
|
||||||
|
cd /home/sunrise/yiliao_ws
|
||||||
|
git revert 87f562d
|
||||||
|
nmcli connection down 'kskbl_2.4G-rdk164' 2>/dev/null || true
|
||||||
|
nmcli connection delete 'kskbl_2.4G-rdk164'
|
||||||
|
nmcli connection modify 'openwrt_5G 1' connection.autoconnect-priority 0
|
||||||
|
```
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# WSL：恢复 .151 文件名、XML 与脚本。
|
||||||
|
cd /home/hikos/Yiliao2026
|
||||||
|
git revert c383338
|
||||||
|
```
|
||||||
|
|
||||||
|
回滚后应停止并重新启动 Domain 22 daemon/ROS 节点，使 participant 重新读取旧 XML。不要删除 `.210` 管理连接、现有策略路由脚本、Domain 23 daemon 或用户 dirty files。
|
||||||
|
|
||||||
|
WSL 最终 XML 完整内容（本节以下为最初 `.151` 版本的历史快照；当前生效版本和精确差异以上述后续实施结果为准）：
|
||||||
|
|
||||||
```xml
|
```xml
|
||||||
<?xml version="1.0" encoding="UTF-8" ?>
|
<?xml version="1.0" encoding="UTF-8" ?>
|
||||||
|
|||||||
Reference in New Issue
Block a user