# 用 Wireshark 抓包分析 SOME/IP 通信：从入门到实战
> **写给谁看**：车载以太网/SOME/IP 初学者、需要联调 ECU 的工程师、以及使用本仓库 **SOME/IP Toolkit**（PyQt 图形工具 + someipyd）做仿真与测试的同事。
> **读完你能做什么**：独立安装与配置 Wireshark、在正确网卡上抓到 SOME/IP 与 SD 报文、用过滤器快速定位问题、把十六进制与「树形解析」对上号，并能与工具底部 **日志面板** 交叉验证。
> **特别声明**：本文是纯文本教程，**不包含真实截图**；凡需「看图」之处，一律用 **文字描述 + Hex Dump + 模拟 Wireshark 协议树** 代替，方便打印、检索与版本管理。
---
## 开篇：把整车通信想象成「邮局 + 快递单号」
如果把车载网络想成一座城市的物流系统，那么：
- **IP 地址**像是「小区门牌号」，告诉包裹该送到哪栋楼；
- **UDP/TCP 端口**像是「楼里的前台窗口编号」，同一栋楼里不同服务各占一个窗口；
- **SOME/IP** 则是在窗口里交接的「标准信封格式」：信封正面（**16 字节消息头**）写清寄件人、收件业务类型、是否回执、会话编号等；信封里（**Payload**）才是你的业务数据（温度、车速、诊断参数……）；
- **SOME/IP-SD（Service Discovery）** 像是「黄页广播」：服务方喊「我在这儿营业」（Offer），需求方喊「谁在提供某某服务？」（Find），想收快讯的人再喊「请给我订阅某某栏目」（Subscribe）。
**Wireshark** 就是你在物流枢纽安装的 **X 光机**：所有经过网线的比特流都会被照一遍，你能看到每一层协议如何拆解、字段如何解释、时间先后如何排列。本文的目标，是教你既会用这台 X 光机，又能把它和 **SOME/IP Toolkit 日志面板** 上的「人类可读流水账」对上账。
---
## 1. Wireshark 简介与安装
### 1.1 Wireshark 是什么（用类比说清楚）
把 **Wireshark** 理解成 **「带解码字典的录像机」**：
1. **录像**：把网卡上经过的帧原样记下来（抓包文件 `.pcap` / `.pcapng`）；
2. **回放**：按时间轴一帧帧查看；
3. **解码**：内置成千上万种「字典条目」（协议解析器 / Dissector），遇到以太网头就按 802.3 拆，遇到 IPv4 就按 RFC 拆，遇到 UDP 再往里看是不是 SOME/IP；
4. **过滤**：像 Excel 筛选一样，只显示你关心的行。
与商业车载工具相比，Wireshark **免费、跨平台、可脚本化**；与 tcpdump 相比，它 **图形化、树形展开、过滤器语法成熟**。对 SOME/IP 来说，官方主线已内置 **SOME/IP 与 SOME/IP-SD 解析器**（版本需足够新，见下文）。
### 1.2 版本建议（和 SOME/IP 解析强相关）
| 场景 | 建议 |
|------|------|
| 个人学习 / 本机回环 | 安装 **Wireshark 4.x** 最新稳定版（Windows 用官方安装包即可） |
| 企业环境 | 以 IT 批准的版本为准；若 SOME/IP 树不显示，优先升级 |
| 离线分析 | 只要本机 Wireshark 版本够新，打开 `.pcapng` 仍可解析 |
**为什么要新版本？** 协议解析器会持续修正：字段命名、长度边界、与 TP（分段）相关的展示等。车载项目周期很长，建议你养成习惯：在报告里 **注明 Wireshark 版本号**，避免「同事打不开解析树」的扯皮。
### 1.3 Windows 安装步骤（详细可操作）
1. 打开浏览器访问 Wireshark 官方网站（`https://www.wireshark.org`），进入 **Download**；
2. 选择 **Windows x64 Installer**；
3. 安装向导中一般会捆绑 **Npcap**（或历史版本里的 WinPcap）：
- **Npcap** 相当于给 Windows 加一层「原始套接字捕获能力」；
- 安装 Npcap 时如弹出「是否支持 loopback（回环）捕获」，**建议勾选**——对本机跑 **SOME/IP Toolkit + 127.0.0.1** 极有帮助；
4. 安装结束重启（按提示操作即可）。
### 1.4 首次启动你要认识的三个区域（文字版「界面导览」）
想象 Wireshark 主窗口是一块 **三明治**：
| 区域（自上而下） | 比喻 | 你要看什么 |
|------------------|------|------------|
| **Packet List**（分组列表） | 电影胶片每一格 | 时间、源/目的 IP、协议列、Info 摘要 |
| **Packet Details**（分组详情） | 生物解剖示意图 | 展开 Ethernet → IP → UDP → SOME/IP |
| **Packet Bytes**（原始字节） | 底片上的银盐颗粒 | 左侧偏移、中间 Hex、右侧 ASCII |
你 80% 的工作流是：**在列表里点一条 → 在中间树里展开 → 在底部 Hex 里核对字节**。
### 1.5 法律与伦理提醒（别跳过）
在 **实车、台架、生产环境** 抓包前，请确认你 **有权** 记录流量；某些地区对「监听通信」有合规要求。学习阶段优先在 **实验室 VLAN** 或 **本机回环** 完成演练。
---
## 2. SOME/IP 插件配置（Wireshark 自带解析器）
### 2.1 重要结论：通常不需要第三方插件
对主线 Wireshark 来说，**SOME/IP 不是「外挂插件」**，而是内置 **Dissector**。你要做的主要是两件事：
1. 确认解析器已启用；
2. 如有需要，调整 **端口解码方式**（UDP/TCP 哪个端口按 SOME/IP 解）。
### 2.2 检查解析器是否启用
用文字描述操作路径（不同语言界面文字略有差异）：
1. 打开 Wireshark，菜单 **Analyze** → **Enabled Protocols…**（或 **分析 → 已启用的协议**）；
2. 在搜索框输入 `someip`；
3. 确认 **SOMEIP** 与 **SOMEIP-SD**（名称以你版本为准）处于勾选状态。
**若未勾选**：抓到的 UDP 负载可能显示为 **Data** 或 **Unknown**，像一本外文小说没翻译——不是没包，是 **没解码**。
### 2.3 解码为（Decode As）：把「未知端口」指给 SOME/IP
SOME/IP 规范里，应用端口常用 **30000–30499** 范围，但具体项目可能不同。若 Info 列显示一堆 **Len=xxx** 而不出现 **SOME/IP**：
1. 在列表中选中一条 **UDP** 报文；
2. 右键 → **Decode As…**；
3. 设置规则：**UDP 端口** `你的服务端口` → **Current** 选 **SOME/IP**（或 **SOMEIP**，以界面为准）；
4. 保存后，同端口后续包会按 SOME/IP 解。
**类比**：Wireshark 默认只认识「常见快递公司的制服」；你告诉它「30555 窗口也是 SOME/IP 快递」，它才会用 SOME/IP 的规则拆信封。
### 2.4 SOME/IP-SD 的默认端口与自动识别
根据 AUTOSAR 实践与大量项目约定：
- **SOME/IP-SD** 常用 **UDP 30490**；
- 组播地址常见 **224.224.224.245**（项目可改）。
本仓库默认配置 `someipyd.json` 中可见类似字段（学习时可对照）：
```json
{
"sd_multicast_address": "224.224.224.245",
"sd_port": 30490
}
```
**Wireshark 往往能对 30490 上的 SD 自动识别**；若不能，同样用 **Decode As** 强制。
---
## 3. 网卡选择与抓包准备
### 3.1 选错网卡 = 在错误的街口蹲点
Wireshark 启动后，主界面会列出 **接口列表**。每个接口名字在 Windows 上可能是：
- `Ethernet` / `以太网`：有线网卡；
- `Wi-Fi`：无线；
- `Adapter for loopback traffic capture`：回环（需 Npcap 支持）；
- 虚拟机：`VMware`、`vEthernet` 等。
**你要选的接口，必须是你业务流量真实经过的那条路。**
### 3.2 本机 SOME/IP Toolkit 场景（强烈建议先练）
当工具配置为 `127.0.0.1`、daemon 与仿真都在本机时：
- 流量可能走 **Loopback**；
- 若抓不到，检查 Npcap 是否启用 loopback；
- 也可临时改为 **真实网卡 IP** 对两台 PC 互通（更接近日后台架）。
### 3.3 交换机镜像（SPAN）与车载 TAP
在台架上，常见三种方式：
| 方式 | 比喻 | 优点 | 注意 |
|------|------|------|------|
| **端口镜像** | 把一条车道的车复制到观察车道 | 不改报文时序 | 交换机要支持；镜像口带宽 |
| **TAP 设备** | 在电缆中间夹听诊器 | 更「物理真实」 | 成本与接线 |
| **ECU 本机抓包** | 在司机口袋里录音 | 方便 | 只能看到该主机收发的 |
### 3.4 抓包前的检查清单（可直接照着勾）
1. **IP 与路由**：`ping` 或对端 ECU 基础连通（若项目允许）；
2. **防火墙**：Windows 防火墙可能干扰本机实验——实验室可临时放宽规则（注意安全边界）；
3. **巨型帧 / VLAN**：若带 **802.1Q VLAN Tag**，Wireshark 可能显示 **QinQ**；长度字段要与项目一致；
4. **时间戳**：Wireshark **View → Time Display Format** 可切换 **绝对时间 / 相对秒 / 毫秒精度**——联调延迟类问题建议用高精度。
### 3.5 开始捕获与停止
1. 双击目标接口，开始抓包；
2. 复现问题（在 Toolkit 里点一次 Method 调用、发布服务等）；
3. 点红色方块 **Stop**；
4. **File → Save As** 保存 `.pcapng`（推荐）——像把 X 光片存档。
---
## 4. 抓取第一个 SOME/IP 包（配合 SOME/IP Toolkit）
### 4.1 实验拓扑（最小闭环）
把下面场景当成「厨房试做第一道菜」：
1. 启动 **SOME/IP Toolkit**（`main.py` 启动的图形程序）；
2. 确认 **someipyd** 守护进程按文档运行（工具内通常有启动/连接状态）；
3. 在 **同一界面 IP**（如 `127.0.0.1`）上添加 **Server** 与 **Client**；
4. 配置一个 **Method**（记下 **Service ID、Method ID、UDP/TCP、端口**）；
5. Wireshark 选对网卡或 Loopback，开始捕获；
6. 在 Client 侧点一次 **调用 Method**；
7. 停止捕获，在过滤栏输入 `someip` 缩小视野。
### 4.2 你期望在列表里看到什么（文字描述「伪截图」）
在 **Packet List** 中，可能出现类似 **Info** 摘要（示意，非固定字符串）：
```text
... UDP 192.168.1.10:52340 → 192.168.1.20:30555 Len=... SOME/IP Request ...
... UDP 192.168.1.20:30555 → 192.168.1.10:52340 Len=... SOME/IP Response ...
```
**像什么？** 像微信聊天记录里两条成对消息：一条「问」，一条「答」。UDP 场景下，**源/目的端口会交换**。
### 4.3 若一条都看不到：最短排查路径
| 现象 | 可能原因 | 下一步 |
|------|----------|--------|
| 完全无 UDP | 网卡选错 / 未走该接口 | 换接口；确认 IP |
| 有 UDP 但无 SOME/IP | 解码器未启用或端口未绑定 | Enabled Protocols；Decode As |
| Toolkit 日志有 TX 但 Wireshark 无 | 本机回环未捕获 | Npcap loopback；或改用实网卡 IP |
| 只有 SD 无应用消息 | 服务未 Offer / Client 未连对端口 | 对照 SD 与服务端口配置 |
### 4.4 与工具日志的「第一性原理」对齐
SOME/IP Toolkit 底部 **日志面板** 列包括：**时间、方向（TX/RX）、Service ID、Method/Event ID、消息类型、返回码、Payload(Hex)、客户端 IP、端口**（见 `gui/log_widget.py` 定义）。
**心法**：Wireshark 告诉你 **链路上客观发生了什么**；日志告诉你 **应用程序如何解释并记录**。二者应 **同一次操作、同一 Session、同一 Client ID** 对齐。
---
## 5. SOME/IP 消息头解析（逐字节对照 Wireshark 显示）
### 5.1 固定 16 字节头：信封正面
SOME/IP 消息以 **16 字节固定头部** 开始，随后是 **Payload（0 或更多字节）**。
下表与仓库内 `SOMEIP_PROTOCOL_DETAIL.md` 一致，便于你跨文档对照：
| 偏移 | 长度 | 字段 | 含义（口语） |
|------|------|------|----------------|
| 0–1 | 2 | Service ID | 哪家店（哪个服务） |
| 2–3 | 2 | Method ID / Event ID | 哪个柜台业务 / 哪路事件 |
| 4–7 | 4 | Length | 从 Client ID 开始到报文末尾的总长度（大端） |
| 8–9 | 2 | Client ID | 谁发起的（对话方标识） |
| 10–11 | 2 | Session ID | 第几单（匹配请求/响应） |
| 12 | 1 | Protocol Version | 协议版本（常见 0x01） |
| 13 | 1 | Interface Version | 接口 Major 版本 |
| 14 | 1 | Message Type | 信封类型：请求/响应/通知… |
| 15 | 1 | Return Code | 结果码（响应里最关键） |
| 16… | N | Payload | 业务数据 |
### 5.2 Length 字段怎么算（最容易翻车的点）
规范含义（教学口径）：
\[
\text{Length} = 8 + N_{\text{payload}}
\]
其中 **8** 来自：`Client ID(2) + Session ID(2) + Protocol(1) + Interface(1) + MsgType(1) + ReturnCode(1)`。
**类比**：Length 不是「整包以太网长度」，也不是「从 Service ID 算起」；它是 **从 Client ID 开始一直到 Payload 结束** 这一段的总长度。
### 5.3 示例 A：4 字节 Payload 的 REQUEST（完整 UDP 负载 = 16+4）
下面给出 **仅 SOME/IP 层** 的连续十六进制（大端），你在 Packet Bytes 里应能逐字节对齐：
```hex
12 34 00 01 00 00 00 0C 00 00 00 01 01 01 00 00 0B B8 5A 32
```
**字段拆解（对照上面的表）**：
```text
Service ID = 0x1234
Method ID = 0x0001
Length = 0x0000000C = 12 = 8 + 4（Payload 4 字节）
Client ID = 0x0000
Session ID = 0x0001
Proto Ver = 0x01
Interface Ver = 0x01
Message Type = 0x00 → REQUEST
Return Code = 0x00 → 请求里常见为 0
Payload = 0B B8 5A 32（4 字节，示例业务数据）
```
### 5.4 模拟 Wireshark 协议树（Packet Details 长什么样）
选中该 UDP 数据报后，中间栏可能呈现如下 **缩进树**（模拟，字段名以你 Wireshark 版本为准）：
```text
User Datagram Protocol, Src Port: 52340, Dst Port: 30555
Source Port: 52340
Destination Port: 30555
Length: ...
Checksum: 0x.... [verified]
SOME/IP
Service ID: 0x1234
Method ID: 0x0001
Length: 12
Client ID: 0x0000
Session ID: 0x0001
Protocol Version: 1
Interface Version: 1
Message Type: REQUEST (0x00)
Return Code: E_OK (0x00)
Payload: 0bb85a32
```
**你怎么练「肉眼对账」？**
1. 在树里点 **Service ID** 这一行；
2. 看底部 Hex 窗是否 **高亮** 了前两个字节；
3. 再点 **Payload**；
4. 看高亮是否跳到 **第 16 字节起始** 的位置。
这就像老师用荧光笔在卷子上划：点哪个字段，荧光笔就落在哪段字节。
### 5.5 示例 B：同一 Session 的 RESPONSE（注意 Message Type 与 Return Code）
假设 Server 回应同样的 Session，并携带 2 字节 Payload `37 13`，且返回码成功：
```hex
12 34 00 01 00 00 00 0A 00 00 00 01 01 01 80 00 37 13
```
解读要点：
```text
Length = 0x0A = 10 = 8 + 2（Payload 2 字节）
Message Type = 0x80 → RESPONSE
Return Code = 0x00 → E_OK（成功）
Payload = 37 13
```
**配对心法**：与请求比对 **Service ID、Method ID、Client ID、Session ID** 四个关键键，像核对 **快递单号 + 收件人手机号**。
---
## 6. 过滤器的使用（`someip`、`someip.serviceid`、`someip.messagetype` 等）
### 6.1 显示过滤器 vs 捕获过滤器
| 类型 | 比喻 | 典型语法 | 场景 |
|------|------|----------|------|
| **捕获过滤器**（Capture Filter） | 录音机只录鼓点 | `udp port 30490` | 长时间抓包省磁盘 |
| **显示过滤器**（Display Filter） | 后期剪辑挑镜头 | `someip && udp.port==30555` | 分析阶段主力 |
本文默认讲 **显示过滤器**（上方绿色输入条）。
### 6.2 基础：只看 SOME/IP
```wireshark
someip
```
像在说：「把所有解码为 SOME/IP 的帧留下来。」
### 6.3 按 Service ID 过滤
```wireshark
someip.serviceid == 0x1234
```
**注意**：Wireshark 里十六进制常用 `0x` 前缀；若语法报错，可尝试十进制写法 `4660`（0x1234）。
### 6.4 按 Message Type 过滤
Message Type 是数值枚举。示例（需与你版本字段名一致，可用 **表达式自动完成** 辅助）：
```wireshark
someip.messagetype == 0x00 # REQUEST（示例）
someip.messagetype == 0x80 # RESPONSE（示例）
someip.messagetype == 0x02 # NOTIFICATION（示例）
```
**技巧**：在 Packet Details 里对 **Message Type** 右键 → **Prepare as Filter** → **Selected**，让 Wireshark 自动生成正确字段名——比背字段名更稳。
### 6.5 组合过滤：像 SQL WHERE 一样拼接
```wireshark
someip && ip.addr==192.168.1.20 && udp.port==30555
```
解释：「SOME/IP 帧，且与 192.168.1.20 有关，且 UDP 端口 30555。」
### 6.6 追踪流（Follow UDP/TCP Stream）
右键某帧 → **Follow → UDP Stream**：
- 像把散落的对话 **按会话拼回一篇聊天记录**；
- 对 **TCP 模式**尤其有用（字节流连续到达，需拼流看应用消息边界）。
### 6.7 常见字段名踩坑说明
不同 Wireshark 版本对字段命名可能略有差异（大小写、下划线）。**最稳**的做法：
1. 选中一条解析成功的 SOME/IP 包；
2. 在树里对目标字段 **Apply as Filter**；
3. 把生成的表达式复制到你的「过滤器笔记本」里。
---
## 7. SD 服务发现报文解析（OfferService、FindService、Subscribe）
### 7.1 先认路：Service ID = 0xFFFF
普通服务消息用你自己的 Service ID；**SD 消息**则像「广播频道」，规范上 **Service ID 固定为 0xFFFF**，Method/Event 区域也有特定约定——Wireshark 会标成 **SOME/IP-SD** 子树。
**类比**：普通 SOME/IP 是「点对点寄信」；SD 是「小区喇叭喊话」。
### 7.2 SD 报文在外形上的识别（文字描述）
在列表 **Info** 列你可能看到类似：
```text
SOME/IP-SD: Offer Service ...
SOME/IP-SD: Find Service ...
SOME/IP-SD: Subscribe Eventgroup ...
```
若仍显示 Raw，优先检查：
- UDP **目的端口是否 30490**（或你项目端口）；
- IP 是否为 **组播**；
- 是否需 **Decode As**。
### 7.3 OfferService（服务上架）
**语义**：Server 向网络声明：「某 Service Instance 在某 Endpoint（IP+Port+Proto）可达。」
**你在树里重点找什么（模拟结构）**：
```text
SOME/IP
Service ID: 0xffff
...
SOME/IP-SD
Flags: ...
Entries
Entry: Offer Service
Service ID: 0x1234
Instance ID: ...
Major Version: ...
Minor Version: ...
Options
IPv4 Endpoint Option
IPv4 Address: 192.168.1.20
L4 Protocol: UDP
Port Number: 30555
```
**分析思路（像侦探）**：
1. **Service ID** 是否与你应用一致？
2. **Endpoint Option** 的 IP/端口是否 **真监听**？（用 `netstat` 或工具面板核对）
3. **Major/Minor** 是否与 Client 期望一致？（不一致常见表现为 Client「永远找不到服务」）
### 7.4 FindService（服务查找）
**语义**：Client 问：「谁提供某服务？」
**现象**：
- 若网络里 **没人 Offer**，你会看到 Find 像 **在空山谷喊话**——只有问没有答；
- 若 **VLAN/组播被交换机吃掉**，Offer/Find 都可能消失。
**过滤器思路**：
```wireshark
udp.port == 30490 && someip
```
然后人工看 SD 子树条目类型。
### 7.5 Subscribe / SubscribeEventgroup（订阅事件组）
**语义**：Client 告诉 Server：「请把某 EventGroup 的事件推给我（或某会话关系）。」
车载里 **Event 通知**往往与 **订阅状态**强绑定。你在 Wireshark 里要确认：
1. Subscribe 是否成功（是否有 ACK / 是否有后续 NOTIFICATION）；
2. **EventGroup ID** 是否与 ARXML / 服务描述一致；
3. 若订阅频繁抖动，观察 **重订阅间隔** 与 **ECU 复位** 是否相关。
### 7.6 一段「虚构但结构合理」的 SD 负载开头（用于对照练习）
> 说明：真实 SD 由 **Header + EntriesArray + OptionsArray** 组成，长度随 Entry/Option 个数变化。下面仅示意 **你可以如何阅读 Hex**（数值为教学编造）：
```hex
FF FF 81 00 00 00 00 01 ... # 仅示意：Service ID 区域常出现 0xFFFF 相关模式
```
**练习方法**：不要背虚构字节；请在真实 pcap 里选中 SD 帧，展开 **SOME/IP-SD**，对每个 Entry 记录：
- Entry Type；
- Service ID / Instance / TTL；
- 关联 Option 索引。
像做 **表格填空**，两轮之后你就能肉眼识别。
---
## 8. Method 调用的请求/响应配对分析
### 8.1 把 Method 调用想成「RPC 电话」
- **REQUEST**：拨号并提问；
- **RESPONSE**：对方回答；
- **ERROR**：对方说「你这问题我没法答」（带返回码原因）。
### 8.2 配对四元组（建议抄在小卡片上）
| 键 | 作用 |
|----|------|
| Service ID | 哪个服务 |
| Method ID | 哪个方法 |
| Client ID | 哪条「客户端线路」 |
| Session ID | 哪一单 |
**只有四者一致**，RESPONSE 才是该 REQUEST 的「官方回执」。
### 8.3 UDP 模式下的时序阅读法
在 Packet List 按时间排序（默认），你会看到：
```text
t=0.000 REQUEST (Client -> Server)
t=0.002 RESPONSE (Server -> Client)
```
**延迟分析**：
- 若间隔 **数毫秒**：通常正常；
- 若 **只有 REQUEST 无 RESPONSE**：Server 崩了、端口没开、Method 未实现、或防火墙丢包；
- 若 **RESPONSE 很快但 Return Code 非 E_OK**：业务拒绝或参数错误。
### 8.4 TCP 模式下的「粘包」心法
TCP 是 **字节流**：Wireshark 可能显示多个 SOME/IP 消息 **在同一个 Segment** 里，也可能 **跨 Segment**。
你要做的是：
1. **Follow TCP Stream** 看整体；
2. 回到分组列表，看 SOME/IP 解析器是否在 **TCP payload** 上切分出多条 SOME/IP；
3. 若解析失败，检查是否开启了 **TP 分段**、是否长度字段被破坏。
### 8.5 示例：REQUEST/RESPONSE 成对 Hex（精简）
**REQUEST**（无 Payload）：
```hex
12 34 00 01 00 00 00 08 00 A1 00 0F 01 01 00 00
```
**RESPONSE**（无 Payload，成功）：
```hex
12 34 00 01 00 00 00 08 00 A1 00 0F 01 01 80 00
```
对比：
```text
Client ID = 0x00A1 一致
Session ID = 0x000F 一致
Message Type: 0x00 -> 0x80
Return Code: 0x00（成功）
```
### 8.6 与 Toolkit 日志对齐的实操建议
当你在工具里点一次 Method：
1. 记日志中 **时间戳**（毫秒）与 **Session**（若日志展示）；
2. Wireshark 用 **时间列**找同一毫秒附近的帧；
3. 若工具显示 TX 而抓包无：优先怀疑 **接口/回环**；
4. 若抓包有而工具无 RX：怀疑 **daemon 未转发** 或 **应用过滤**。
---
## 9. Event 通知报文分析
### 9.1 Event 与 Method 的最大区别
- **Method**：典型是「问—答」；
- **Event**：典型是「播—收」，消息类型多为 **NOTIFICATION（0x02）**，由 Server（或发布方）主动发。
**类比**：Method 像你去柜台查询；Event 像 **微信公众号推送**——你得先 **订阅**（SD/EventGroup），否则推送可能不来。
### 9.2 Event ID 的范围直觉
规范里 Event ID 常落在 **0x8001** 等高位区间（教学上常称「Event 区段」）。实际以你项目 ARXML 为准。
### 9.3 示例：NOTIFICATION 带 6 字节 Payload
```hex
12 34 80 01 00 00 00 0E 00 00 00 01 01 01 02 00 AA BB CC DD EE FF
```
阅读要点：
```text
Service ID = 0x1234
Method/Event = 0x8001 ← 在 NOTIFICATION 语境下视作 Event ID
Length = 0x0E = 14 = 8 + 6
Message Type = 0x02 → NOTIFICATION
Return Code = 0x00
Payload = AA BB CC DD EE FF
```
### 9.4 模拟协议树（帮助你建立视觉记忆）
```text
SOME/IP
Service ID: 0x1234
Event ID: 0x8001
Message Type: NOTIFICATION (0x02)
Return Code: E_OK (0x00)
Payload: aabbccddeeff
```
### 9.5 常见误区
| 误区 | 真相 |
|------|------|
| 「有 Event 就一定能抓到」 | 可能未订阅或实例不匹配 |
| 「NOTIFICATION 一定有 Payload」 | Payload 可能为 0 长度（仍合法，视接口） |
| 「Event 一定走 UDP」 | 项目可能走 TCP；要以 Endpoint 为准 |
---
## 10. Field（Getter / Setter / Notifier）报文分析
### 10.1 Field 不是新协议，而是「三种动作的打包概念」
在 AUTOSAR/SOME/IP 世界观里，**Field** 通常包含：
1. **Getter**：读值（Method）；
2. **Setter**：写值（Method）；
3. **Notifier**：值变化通知（Event）。
本仓库 `FieldConfig` 的注释写得很直白：`Field = Getter(Method) + Setter(Method) + Notifier(Event)`。
### 10.2 你在 Wireshark 里怎么认？
- **Getter/Setter**：看 **REQUEST/RESPONSE**，Method ID 对应 Getter/Setter；
- **Notifier**：看 **NOTIFICATION**，Event ID 对应 Notifier。
### 10.3 与 Toolkit UI 操作对齐（来自 USER_GUIDE 的心法）
工具里：
- **Get**：发送 Getter 请求；
- **Set**：发送 Setter 请求；
- **Notifier**：作为 Event，需要 **订阅对应 EventGroup**。
**Wireshark 验证路径**：
1. 先看到 SD Subscribe 与后续 NOTIFICATION；
2. 或先看到 Setter RESPONSE 成功，再紧跟 Notifier（取决于实现与策略）。
### 10.4 示例思路（不写死项目 ID）
假设 Getter 的 Method ID = `0x0002`，Setter = `0x0003`，Notifier Event = `0x8002`：
- 抓 **Get**：过滤 `someip.messagetype==0x00 && someip.methodid==0x0002`（字段名以自动完成为准）；
- 抓 **Set**：同理替换 ID；
- 抓 **Notifier**：过滤 `someip.messagetype==0x02 && someip.methodid==0x8002` 或 Event 字段名。
### 10.5 返回码与「写成功但读不到」类问题
当你 Setter RESPONSE `E_OK`，但 Getter 仍读到旧值：
- 可能 **Server 内部状态机未更新**；
- 可能 **你读的是另一个 Instance**；
- 可能 **Client 连错 Endpoint**（SD Offer 指错端口）。
此时 Wireshark + 日志对齐 **Service/Instance/Endpoint** 三角信息，比盲改代码快得多。
---
## 11. TCP 模式 vs UDP 模式在 Wireshark 中的区别
### 11.1 传输层性格对比（形象）
| 维度 | UDP | TCP |
|------|-----|-----|
| 类比 | 发短信：每条独立 | 打电话：连续流 |
| 无序/丢包 | 应用要自己处理（或上层保证） | 重传由 TCP 保证 |
| Wireshark 观感 | 一帧往往就是一个 UDP 数据报里的 SOME/IP | 可能需要 **重组**、**多消息同段** |
### 11.2 端口与连接
- **UDP**：关注 **UDP 端口**；无连接状态；
- **TCP**：关注 **三次握手**、**PSH/ACK**、**窗口**；SOME/IP 在 **TCP payload** 内。
### 11.3 Wireshark 分析 TCP 上 SOME/IP 的流程建议
1. 先用 `tcp.port == xxxx` 找到连接；
2. **Follow TCP Stream**；
3. 看是否每条 SOME/IP 都有合法 **Length**；
4. 若出现 **Malformed** 提示：优先怀疑 **半包**、**TLS 封装**（若项目加密）、**自定义封装**。
### 11.4 本仓库相关配置提示
`someipyd.json` 可能出现 `use_tcp`、`tcp_port`（如 30500）等字段，表示 **daemon 与控制面**可能走 TCP（与学习场景相关）。
**请注意区分**：
- **daemon 通道** vs
- **应用 SOME/IP 服务通道**（你在 ARXML/工具里给 Method 配的 UDP/TCP）
别把两条「TCP 河流」混成一条。
### 11.5 何时更该用 TCP 模式抓 Method
大数据、可靠传输需求、或厂商实现偏好 TCP 时：
- 用 Wireshark 的 **TCP Analyze Sequence Numbers** 辅助判断重传；
- 若延迟抖动大，对比 **IO Graph**（见高级技巧章节）。
---
## 12. 常见问题排查案例（附「截图的文字描述」）
> 本章每个案例都给出：**现象（像截图一样的文字）→ 证据（过滤器/字段）→ 结论 → 处理**。
### 案例 A：能看到 ARP，看不到 UDP
**文字描述（Packet List）**：
```text
1 0.000000 ARP Who has 192.168.1.20? Tell 192.168.1.10
2 0.000123 ARP 192.168.1.20 is at aa:bb:cc:dd:ee:ff
... 之后没有 UDP ...
```
**分析**：二层可能通，但 **没有更高层业务** 或 **抓包点不对**。
**下一步**：确认 Toolkit 是否真的发出 UDP；确认是否应在 **镜像口** 抓。
### 案例 B：UDP 有，SOME/IP 不解析
**文字描述（Details）**：
```text
User Datagram Protocol
Source Port: 52340
Destination Port: 30555
Data (42 bytes)
```
**分析**：Wireshark 把负载当生肉。
**处理**：`Decode As` 将 30555 解为 SOME/IP；检查 **Enabled Protocols**。
### 案例 C：REQUEST 重复出现，无 RESPONSE
**文字描述**：
```text
... SOME/IP Request Session=0x0007 ...
... SOME/IP Request Session=0x0008 ...
... SOME/IP Request Session=0x0009 ...
```
**分析**：Client 在 **超时重试** 或 **上层不断触发**。
**排查**：Server 进程、端口监听、Service ID 是否匹配、Method 是否注册。
### 案例 D：RESPONSE Return Code = E_UNKNOWN_METHOD
**树关键行（模拟）**：
```text
SOME/IP
Message Type: RESPONSE (0x80)
Return Code: E_UNKNOWN_METHOD (0x03)
```
**分析**：你呼叫的 **Method ID** 在 Server 侧不存在或被禁用。
**处理**：对齐 ARXML/工具配置；用过滤器锁定 `methodid`。
### 案例 E：SD Offer 的端口与真实监听不一致
**SD 树（模拟）**：
```text
IPv4 Endpoint Option
IPv4 Address: 192.168.1.20
Port: 30555
```
但操作系统显示监听在 `30556`：
```text
# 文字描述 netstat 结果（示例）
UDP 192.168.1.20:30556 *:*
```
**分析**：**Offer 撒谎**或 **配置漂移**。
**处理**：修正 SD 发布逻辑或修正监听端口，确保「广告」和「柜台」一致。
### 案例 F：组播 SD 只有单方向
**现象**：只看到 Find，看不到 Offer；或相反。
**分析**：IGMP、VLAN、路由器组播转发、镜像方向。
**处理**：换抓包点；让网络同事确认 **组播域**。
---
## 13. 高级技巧：统计、IO 图、时序分析、导出
### 13.1 Statistics → Protocol Hierarchy（协议分级）
**像超市销量报表**：一眼看 SOME/IP 占总流量百分之几，是否被 **广播风暴** 淹没。
### 13.2 Conversations（会话）
**看谁在和谁说话**：按 IP:Port 聚合，找 **最忙的一对端点**。
### 13.3 IO Graphs（IO 图）
**把流量变成曲线**：Y 轴选 **Packets/s** 或 **Bytes/s**，过滤表达式写 `someip` 或更细。
**用途**：
- 观察 **周期 Event** 是否稳定；
- 观察 **突发调用** 是否打满链路。
**文字描述图的样子**：
```text
Packets/s
^
10 | * * * * * ← 周期尖峰（像心跳）
5 | * * * * * * * * *
0 +---------------------------------> time
```
### 13.4 时序分析：时间列 + Delta 列
开启 **相对时间** 或 **相对选定包** 的时间显示：
- 选中 REQUEST，看下一帧 RESPONSE 的 **Delta**；
- 像用秒表量 **RTT**。
### 13.5 导出对象与文本
| 需求 | 菜单路径（文字） |
|------|------------------|
| 导出 **特定包** | File → Export Specified Packets |
| 导出 **JSON/PDML**（给脚本） | File → Export Packet Dissections |
| 复制 **Hex** | Packet Bytes 右键 Copy |
**团队协作建议**：附 `.pcapng` + **过滤器表达式** + **Wireshark 版本**。
---
## 14. 与 SOME/IP Toolkit 日志面板对照使用
### 14.1 日志面板列含义（与代码一致）
工具 `LogWidget` 的列包括：
```text
时间 | 方向 | Service ID | Method/Event ID | 消息类型 | 返回码 | Payload(Hex) | 客户端 IP | 端口
```
**方向**：
- **TX**：本工具认为「发出」；
- **RX**：本工具认为「收到」。
### 14.2 推荐对照表（建议你打印）
| Wireshark 观察点 | 日志面板对应 |
|------------------|--------------|
| `ip.src/ip.dst` | 客户端 IP / 对端推断 |
| `udp.srcport/dstport` | 端口列 |
| `someip.serviceid` | Service ID |
| `someip.methodid` / Event | Method/Event ID |
| `someip.messagetype` | 消息类型（REQUEST/RESPONSE/NOTIFICATION） |
| `someip.returncode` | 返回码 |
| Payload 十六进制 | Payload 列 |
### 14.3 实战工作流（高效）
1. 工具复现 1 次问题；
2. 日志里 **复制** 关键行（支持 Ctrl+C / 导出）；
3. Wireshark 用 **时间戳 + Service ID + Session** 定位帧；
4. 在 Wireshark 确认 **网络客观事实**；
5. 回到工具确认 **配置与业务逻辑**。
### 14.4 典型「对不上」的解释框架
| 情况 | 解释 |
|------|------|
| 日志有 TX，抓包没有 | 抓包网卡/回环问题，或非网络路径（例如未真正发出） |
| 抓包有，日志无 RX | daemon 未连接、过滤、或应用层丢弃 |
| 两边都有但字段不同 | 看是否经过 **中间件改写**（NAT、网关、仿真层） |
---
## 15. 实战演练：完整抓包分析一次 Method 调用过程
> 目标：从「点击按钮」到「确认 REQUEST/RESPONSE 成对」，形成肌肉记忆。
### 15.1 前置条件（检查清单）
1. Wireshark 安装并能抓 **Loopback 或目标网卡**；
2. SOME/IP Toolkit 启动，daemon 正常；
3. 已配置 **Server**（监听某 UDP 端口）与 **Client**（指向正确 IP/端口）；
4. 选定 Method：`Service ID = 0x1234`，`Method ID = 0x0001`（示例）；
5. 清空日志面板（可选）；开始捕获。
### 15.2 操作步骤（逐步）
1. Wireshark **Start**；
2. Toolkit Client 点击 **调用 Method**；
3. Wireshark **Stop**；
4. 过滤器：`someip && someip.serviceid==0x1234`；
5. 应该看到 **2 条主帧**（UDP 场景）：REQUEST 与 RESPONSE。
### 15.3 预期 Packet List（文字模拟）
```text
No. Time Source Destination Protocol Info
12 0.000000 192.168.1.10 192.168.1.20 UDP SOME/IP Request ...
13 0.000513 192.168.1.20 192.168.1.10 UDP SOME/IP Response ...
```
### 15.4 展开 REQUEST（模拟树 + Hex 对齐）
**Packet Bytes（UDP Payload 起始）**：
```hex
12 34 00 01 00 00 00 0C 00 A1 00 2A 01 01 00 00 01 00 00 00
```
**阅读**：
```text
Service ID 0x1234, Method 0x0001
Length = 0x0C → Payload 4 字节
Client ID = 0x00A1
Session ID = 0x002A
Proto=1, Interface=1
Message Type = REQUEST
Return Code = 0x00
Payload = 01 00 00 00（示例：一个 uint32 参数）
```
### 15.5 展开 RESPONSE（强调 Return Code 与 Payload）
```hex
12 34 00 01 00 00 00 0A 00 A1 00 2A 01 01 80 00 00 2A
```
```text
Message Type = RESPONSE (0x80)
Return Code = E_OK (0x00)
Payload = 00 2A（示例返回 2 字节）
```
### 15.6 与日志面板逐列核对
假设日志出现两行：
```text
12:00:01.234 TX 1234 0001 REQUEST 00 01000000 192.168.1.10 52340
12:00:01.235 RX 1234 0001 RESPONSE 00 002A 192.168.1.10 52340
```
你要口头复述：
1. **Service/Method** 一致；
2. **Session**（若日志展示）应与抓包一致；
3. **Payload** 与 Packet Bytes 一致；
4. **时间差**与 Wireshark Delta 一致量级。
### 15.7 复盘问题清单（练完后自测）
1. 你能不看文档说出 **Length** 的含义吗？
2. 你能用过滤器 **10 秒内**定位某 Method 的所有调用吗？
3. 你能解释 **为什么 RESPONSE 的 Message Type 是 0x80** 吗？
4. 你能判断 **没有 RESPONSE** 时下一步先查 Server 还是先查网络吗？
---
## 附录 A：Message Type 速查（与仓库枚举一致）
| 值 | 名称 | 记忆钩子 |
|----|------|----------|
| 0x00 | REQUEST | 「问」 |
| 0x01 | REQUEST_NO_RETURN | 「丢下就跑」 |
| 0x02 | NOTIFICATION | 「推送」 |
| 0x80 | RESPONSE | 「答」 |
| 0x81 | ERROR | 「答不了」 |
TP 分段相关（0x20/0x21/0x22/0xA0/0xA1）像 **拆包裹分批送货**，大报文才常见。
---
## 附录 B：Return Code 常见值（工具侧已定义部分）
| 值 | 含义（简） |
|----|------------|
| 0x00 | E_OK |
| 0x02 | E_UNKNOWN_SERVICE |
| 0x03 | E_UNKNOWN_METHOD |
| 0x08 | E_WRONG_INTERFACE_VERSION |
完整列表见 `core/models.py` 中 `ReturnCode`。
---
## 附录 C：推荐阅读顺序（与本仓库文档衔接）
1. `USER_GUIDE.md`：先把 Toolkit 跑起来；
2. `SOMEIP_PROTOCOL_DETAIL.md`：把字节级定义吃透；
3. 本文：把 **链路与工具日志** 打通。
---
## 结语
Wireshark 不会替你「懂业务」，但它会让你 **无法抵赖地看到事实**：端口、长度、会话、返回码、时序。SOME/IP 也不神秘，它只是 **车载以太网里一种带单号的信封格式**；SD 则是 **让信封能送达正确窗口的黄页系统**。
把本文的练习做三遍：
- 第一遍照抄步骤；
- 第二遍闭眼看 Hex 口述字段；
- 第三遍只看 Toolkit 日志就能预测 Wireshark 里会出现什么。
到那时，你在台架上的每一次联调，都会少一句「是不是网络问题？」的玄学，多一句「我把 SESSION 对上了，问题在 Server 返回值」的笃定。
---
**文档版本**：v1.0
**适用工具**：Wireshark 4.x（建议）；SOME/IP Toolkit（本仓库）
**维护建议**：随 Wireshark 字段名变化，定期用「右键 Prepare/Apply Filter」更新本文过滤器示例。
---
## 附录 D：把安装与权限问题一次说透（扩展阅读）
### D.1 Npcap 与 WinPcap 的「代际差」
老玩家记得 **WinPcap**，新环境应优先 **Npcap**。可以把它们理解成：
- **WinPcap**：老式录音机，能录很多台，但对 **回环** 支持弱；
- **Npcap**：新式录音机，支持更多模式，和 Windows 10/11 兼容更好。
若你安装 Wireshark 后列表里 **没有接口** 或 **无法开始捕获**，优先重装 Npcap 并勾选：
- **Install Npcap in WinPcap API-compatible Mode**（兼容老软件）；
- 需要本机回环时勾选 **Support loopback traffic**（选项名称以安装向导为准）。
### D.2 「需要管理员身份运行」到底在管什么？
在 Windows 上，原始套接字捕获有时涉及权限。你可以把 **管理员启动 Wireshark** 理解为：
- 给 X 光机 **开更高权限的门**，让它能进更多通道。
企业环境若禁止管理员运行，可使用 **USBPcap** 专用方案或 **远程捕获**（高级，不在此展开）。
### D.3 中文界面与英文界面：如何自学对照
Wireshark 社区资料以英文为主。建议你：
1. 菜单 **Help → About** 记版本；
2. 固定使用一种界面语言（中文或英文）以减少认知切换；
3. 把常用菜单路径记成「肌肉记忆」：**Capture Options / Preferences / Decode As / Follow Stream**。
### D.4 磁盘与内存：长时间抓包的「垃圾桶容量」
把车联网测试想成 **24 小时监控录像**：
- 抓包文件会迅速膨胀；
- 笔记本磁盘满了会像 **监控硬盘红警**——丢帧、崩溃、文件损坏。
建议：
1. 捕获前用 **Capture Filter** 限制端口；
2. 使用 **Ring Buffer**（环形缓冲）按文件大小轮转；
3. 实验结束立刻 **压缩归档** `.pcapng`。
---
## 附录 E：SOME/IP-SD 的「阅读算法」（像读表格一样读 Entries/Options）
### E.1 为什么 SD 比应用报文更难？
应用报文像 **单行发票**：Service/Method/Length 一顺溜。
SD 像 **一叠发票 + 一叠附件**：**Entries** 描述「我要做什么」，**Options** 描述「地址/TTL/负载均衡偏好」等，二者通过索引互相关联。
### E.2 你手里应拿一支笔：建议记录模板
对每一条 SD 报文，记录：
| 字段组 | 你写什么 |
|--------|----------|
| 传输 | 源 IP:Port → 目的 IP:Port；是否组播 |
| 会话 | Request ID / 与规范相关的标识（以解析树为准） |
| Flags | 重启标志等（用于判断是否重建会话） |
| Entries | 每条 Entry 的类型、Service、Instance、Major、TTL |
| Options | IPv4/IPv6 Endpoint、Configuration 等 |
### E.3 Offer + IPv4 Endpoint 的「一致性校验」口诀
把下面三句话背下来，在台架上默念：
1. **Offer 的 Service ID** 必须是我要找的服务吗？
2. **Endpoint 的 IP** 是 ECU 的真实地址吗（不是 0.0.0.0 之类异常）？
3. **端口与协议** 与我在 Wireshark 应用层看到的一致吗？
任何一句回答「否」，你就不用先去查 Payload 编码了——**先修广告**。
### E.4 Find 与 Offer 的「时间戏剧」
想象一场话剧：
- **第一幕**：Client 发 Find（问）；
- **第二幕**：Server 发 Offer（答）；
- **第三幕**：Client 发 Subscribe（订）；
- **第四幕**：Server 开始推 Event（播）。
Wireshark 是 **剧本全文**。你只抓到第二幕却抱怨「没有订阅」——那是你 **入场太晚** 或 **过滤太宽**。
---
## 附录 F：分段传输（TP）在 Wireshark 里长什么样？
### F.1 为什么需要 TP？
当 Payload 大到 **单帧 UDP 放不下** 或 TCP 流需要明确边界时，规范提供 **Transport Protocol（TP）** 相关消息类型（如 TP_REQUEST、TP_RESPONSE 等，见 `SOMEIP_PROTOCOL_DETAIL.md`）。
**类比**：普通 SOME/IP 像 **一整车砖一次卸完**；TP 像 **一车车分批卸**，每车带 **第几车/是否最后一车** 的标记。
### F.2 你在 Wireshark 里要警惕什么？
1. **单条 TP 片段**看起来「很短」，但业务上它只是一块拼图；
2. 解析器可能提供 **重组视图**（取决于版本与实现）；
3. 若重组失败，优先检查 **长度字段**、**丢失片段**、**乱序**。
### F.3 与「普通 REQUEST」区分的心法
看到 Message Type 落在 TP 区间时，把你的分析目标从「这一帧的 Payload 含义」切换为：
- **重组后的完整 Payload** 是什么？
- **Session** 是否在同一重组会话内？
- **是否伴随 ERROR/TP_ERROR**？
---
## 附录 G：过滤器「成语手册」（可复制粘贴慢慢积累）
> 提示：字段名以你本机 Wireshark 自动生成为准；下列为教学表达。
```wireshark
# 只看 SD 端口（捕获阶段常用思路，显示过滤示例）
udp.port == 30490
# SOME/IP 且排除 SD 服务 ID（思想示例：有些版本字段不同，需自动完成）
someip && !(someip.serviceid == 0xffff)
# 某个 Client 的所有会话（Client ID 示意 0x00a1）
someip.clientid == 0x00a1
# 某个 Session 的全链路（Session ID 示意 0x002a）
someip.sessionid == 0x002a
# 只看错误响应（Return Code 非 0，注意：请求里也可能为 0）
someip.messagetype == 0x80 && someip.returncode != 0
```
**记忆法**：把过滤器当成 **SQL**：
- `&&` 是 AND；
- `||` 是 OR；
- `!` 是 NOT。
---
## 附录 H：更多「伪截图」排查剧本（扩展案例）
### 案例 G：IP 分片导致 UDP 载荷「看不见」
**文字描述**：
```text
Frame 100: IPv4, More fragments: Yes
Frame 101: IPv4, More fragments: No
```
**分析**：SOME/IP 可能在 **重组后** 才完整。
**处理**：确认 Wireshark **重组**设置；观察 **IPv4 Reassembled** 相关行。
### 案例 H：VLAN Tag 导致你以为「端口错了」
**现象**：同样的 UDP 端口，在不同镜像口看到不同外层封装。
**分析**：**802.1Q** 改变了「帧的外壳」，但 **IP/UDP/SOME/IP** 内核仍可一致。
**处理**：在思想上把「物理口」与「逻辑网络」分开。
### 案例 I：两台 PC 对跑 Toolkit，Session 增长很快
**现象**：Session ID 每次调用递增，像 **取号机** 一直跳号。
**分析**：这通常正常；异常在于 **跳号但配对失败**。
**处理**：用 `someip.sessionid` 过滤，检查是否 **重复 SESSION 复用**（少见，多半是抓包重复发送）。
### 案例 J：Return Code 正常但业务解析失败
**现象**：`E_OK` 但上位机显示乱码。
**分析**：网络层「送达成功」≠ 应用层「语义正确」。
**处理**：对齐 **序列化规则**（大小端、对齐、padding）；用 Payload Hex 与 ARXML/IDL 对照。
---
## 附录 I：高级技巧补全——专家常用的「隐形按钮」
### I.1 `tcp.analysis` 一族过滤器
例如查找重传（示意）：
```wireshark
tcp.analysis.retransmission
```
像在高速公路上标记「这辆车刚才掉头重跑了一遍」。
### I.2 颜色规则（Coloring Rules）
把 **SOME/IP ERROR**、**Return Code != 0**、**SD Subscribe** 设成不同背景色：
- 列表会像 **交通信号灯**，异常一眼突出。
### I.3 注释与标记（Packet Comment / Mark）
对关键帧 `Ctrl+M` 标记，像给胶片贴 **便签**：
- 联调报告里写「见 Frame 1234」比截图更轻量。
### I.4 导出特定包给供应商
**File → Export Specified Packets → Displayed**，像把一整部电影剪成 **30 秒预告片**：
- 供应商更快定位，你也少泄露无关流量。
---
## 附录 J：与 `SOMEIP_PROTOCOL_DETAIL.md` 的「双书并行」学习法
建议你开两个窗口：
1. **协议细节文档**：看 **定义与公式**；
2. **本文**：看 **Wireshark 与工具链**。
每读完一节，做一次 **10 分钟小实验**：
- 改一个 Method ID；
- 故意改错 Interface Version；
- 观察 Return Code 与工具日志如何同时变化。
这叫 **负向测试学习法**：像学游泳时故意呛一口水，你会更清楚「呼吸节奏」为什么重要。
---
## 附录 K：术语表（中英对照，方便搜资料）
| 中文 | 英文关键词 |
|------|------------|
| 解析器 | Dissector |
| 显示过滤器 | Display Filter |
| 捕获过滤器 | Capture Filter |
| 服务发现 | Service Discovery (SD) |
| 请求/响应 | Request / Response |
| 通知 | Notification |
| 事件组 | Eventgroup |
| 负载 | Payload |
| 会话 | Session |
| 接口主版本 | Major Version / Interface Version |
---
## 附录 L：实战演练「加长版」——从 SD 到 Method 再到 Event（文字分镜）
> 这一节把第 15 章扩展为「整集连续剧」，帮助你建立端到端观。
### L.1 分镜 1：开机后的 SD 世界
**动作**：上电、启动服务、Client 启动。
**Wireshark**：过滤 `udp.port==30490`。
**你应能叙述**：网络里谁先说话？Offer 是否出现？TTL 大概是多少？
### L.2 分镜 2：应用端口握手前的「心理建设」
**动作**：确认 Client 配置的端口与 Offer Endpoint 一致。
**Wireshark**：对应用端口过滤 `udp.port==30555`（示例）。
**叙述**：即使没有 Method 调用，有时也能看到 **心跳/Keep-alive**（取决于实现）。
### L.3 分镜 3：Method 调用（主线剧情）
重复第 15 章步骤，但额外记录：
- **Request 的 Client ID** 是否固定？
- **Session** 是否递增？
- **RTT** 是否稳定？
### L.4 分镜 4：订阅与 Event（支线并入主线）
**动作**：在 Toolkit 的 Event 监听里完成订阅。
**Wireshark**：先看 SD Subscribe 相关条目，再看 `someip.messagetype==0x02`。
**叙述**：通知是否周期？是否只在值变化时发送？
### L.5 分镜 5：收尾——把 pcap 变成证据链
输出三件东西：
1. `.pcapng` 文件；
2. 一份 **过滤器列表**（你用过哪些）；
3. 一份 **时间线说明**（人类语言 10 行以内）。
这就是车载联调里最受欢迎的「短报告」：**轻、准、可复核**。
---
## 附录 M：安全、隐私与数据治理（工程师也要懂一点）
车载数据可能包含：
- 车辆识别相关信息；
- 内部网络拓扑；
- 未公开的业务参数。
**建议**：
1. 实验 pcap **脱敏**（替换 IP、裁剪 Payload）；
2. 对外分享只给 **必要帧**；
3. 公司仓库提交前确认 **无客户机密**。
这不是形式主义，是 **职业信誉**。
---
## 附录 N：最后的类比——你现在已经拥有的「三件武器」
1. **Wireshark**：链路的 X 光机；
2. **SOME/IP Toolkit 日志**：应用的日记本；
3. **协议文档（字节级）**：法律的条文。
联调时，永远 **让事实先行**：先看 X 光，再读日记，最后对条文。你会发现，很多「玄学问题」其实只是 **Endpoint 写错了一位数字** 或 **Session 没配对**。
---
**文档版本**：v1.1（扩充至满足长文实战需求）
**字符维护说明**：本文持续扩展附录与案例，便于团队培训与复盘使用。
---
## 附录 O：Wireshark 列定制与 Info 列「读心术」（再补一章，专治眼花）
### O.1 为什么默认列不够？
默认列表像「超市小票」：只有时间、源、目的、协议、Info。对 SOME/IP 来说，你往往还想一眼看到 **Service ID**、**Message Type**、**Session**，否则每次都要点开详情，像 **买一瓶水却非要走财务部报销**。
### O.2 添加自定义列的思路（文字操作说明）
在 Wireshark 中可以通过 **列首右键 → Column Preferences**（路径以版本为准）增加基于字段的列，例如：
- `someip.serviceid`
- `someip.sessionid`
- `someip.returncode`
**类比**：把收银小票改成「带条形码 + 会员等级 + 积分」的增强版，扫一眼就知道是不是你要的那一单。
### O.3 Info 列到底值不值得信？
Info 是解析器生成的 **摘要字符串**，方便人类，但 **不是权威数据源**。权威永远来自：
1. 协议树字段；
2. Hex 窗高亮；
3. 必要时手工计算 Length。
**典型坑**：不同版本 Info 字符串格式不同；TP 片段的 Info 可能让你误以为「这是一条完整业务报文」。
### O.4 建议的「车载 SOME/IP 桌面布局」
1. 过滤器条：固定放常用表达式；
2. 列表列：至少加 **Service ID + Session**；
3. 详情树：默认展开到 UDP/TCP；
4. Hex：开启 **Show as…** 中的偏好（按你习惯）。
### O.5 与 Toolkit 联调时的「双屏工作法」
左屏 Wireshark，右屏 Toolkit：
- 左手停捕获、右手点调用；
- 眼睛先看 **日志时间戳**，再看 **Wireshark 第一条新帧**。
这套动作重复二十次后，你会形成 **肌肉记忆**：不是「我会用工具」，而是 **我知道问题会先在哪一屏冒出来**。
### O.6 练习作业（不计分，但很有用）
请在实验环境里完成并口述答案：
1. 不点开详情，仅凭 **自定义列** 找出今天最后一次 `RESPONSE` 的 Session。
2. 用过滤器列出所有 `Return Code != E_OK` 的帧，并解释每一条的业务含义（允许查表）。
3. 把一次完整抓包导出 **Displayed**，文件大小是否明显下降？下降说明你的过滤器是否足够「锋利」？
完成这三题，你就从「会抓包」升级到 **会用抓包做项目管理**——知道怎么给同事一份 **小而硬** 的证据包。
扫一扫
82
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
