3. DoIP连接建立与路由激活：DoIP节点发现、车辆声明报文、路由激活流程、连接状态机
好，咱们进入正题。这一章讲的是DoIP连接建立的核心流程。说白了，就是你的诊断工具怎么找到车上的ECU，怎么跟它“握手”，然后怎么激活路由开始干活。
我个人习惯把这一章看作是整个DoIP通信的“敲门砖”。门敲不开，后面SOME/IP、UDS什么的都白搭。我在项目里见过太多因为连接建立阶段出问题，导致后面排查半天才发现是“门”没敲对的情况。
3.1 DoIP节点发现：谁在车上？
你想想看，你的诊断仪（Tester）一上电，连到车载网络里。它怎么知道车上有哪些ECU支持DoIP？总不能一个个去猜吧？
这里就有两个关键动作：车辆声明报文和节点发现请求。
3.1.1 车辆声明报文（Vehicle Announcement Message）
车辆上的DoIP网关（通常是中央网关）上电后，会主动发一个广播报文。这个报文就是告诉整个网络：“嘿，我在这儿，我是这辆车的DoIP实体。”
这个报文长什么样？我贴个关键字段：
| 字段名 | 长度（字节） | 说明 |
|---------------------|--------------|--------------------------------------|
| 协议版本 | 1 | 当前通常是0x02（ISO 13400-2:2012） |
| 反向协议版本 | 1 | 与协议版本相同，用于兼容性检查 |
| 负载类型 | 2 | 0x0004（车辆声明报文） |
| 负载长度 | 4 | 后续数据长度 |
| VIN | 17 | 车辆识别码 |
| 逻辑地址 | 2 | DoIP实体的逻辑地址，通常是0x0E00 |
| EID（实体ID） | 6 | 基于MAC地址或唯一标识 |
| GID（组ID） | 6 | 用于分组管理，通常为0 |
| 进一步动作标志 | 1 | 0x00表示无特殊动作 |
| VIN-GID同步状态 | 1 | 0x00表示VIN与GID未同步 |
嗯，这里要注意。车辆声明报文是周期性发送的，默认周期是3秒。为什么？因为诊断仪可能不是一直连着网络，它可能中途加入。所以网关得不停地“刷存在感”。
3.1.2 节点发现请求（DoIP Entity Status Request）
除了被动等待，诊断仪也可以主动出击。它发送一个0x0001类型的请求报文（DoIP实体状态请求），网关收到后，会回复一个包含自身状态信息的响应。
这个响应里会告诉你：
- 节点是否处于路由激活状态
- 最大支持的同时连接数
- 当前已建立的连接数
- 等等
说白了，就是诊断仪在问：“你忙不忙？能不能接活？”
3.2 路由激活流程：建立通信通道
找到节点了，下一步就是激活路由。这一步很关键，它决定了诊断仪能不能跟车上的ECU进行后续的UDS诊断通信。
路由激活的流程，我习惯用三步来记：
- 诊断仪发送路由激活请求
- 网关验证并回复激活响应
- 双方进入工作状态
3.2.1 路由激活请求报文
诊断仪发送的请求报文，负载类型是0x0005。里面包含几个关键信息：
- 源逻辑地址：诊断仪自己的逻辑地址，通常是0x0E80
- 激活类型：0x00表示默认激活，0x01表示带安全认证的激活
- 保留字节：用于未来扩展
// 路由激活请求报文示例（十六进制）
// 协议版本: 0x02
// 负载类型: 0x0005
// 源逻辑地址: 0x0E80
// 激活类型: 0x00
02 02 00 05 00 00 00 07 0E 80 00 00 00
3.2.2 路由激活响应
网关收到请求后，会检查源逻辑地址是否合法、是否重复。如果一切正常，就回复一个0x0006类型的响应报文。
响应里最重要的字段是响应码：
| 响应码 | 含义 | 说明 |
|---|---|---|
| 0x00 | 成功激活 | 一切正常，可以开始通信 |
| 0x01 | 连接被拒绝 | 网关资源不足或配置错误 |
| 0x02 | 源地址冲突 | 已经有其他连接使用了该逻辑地址 |
| 0x03 | 需要安全认证 | 网关要求先进行安全验证 |
| 0x04 | 未知目标地址 | 网关不认识这个逻辑地址 |
嗯，这里有个坑。响应码0x03（需要安全认证）在量产项目中越来越常见。因为现在车厂对网络安全要求很高，不允许随便一个诊断仪就能连上车内网络。
3.3 连接状态机：DoIP通信的生命周期
DoIP的连接不是一直开着的。它有一个清晰的状态机，管理着从建立到关闭的整个过程。
我个人习惯把状态机画成一张图，但这里我用文字描述一下：
- Listen（监听）：网关在TCP端口（默认13400）上监听，等待诊断仪连接
- Socket Established（套接字已建立）：TCP三次握手完成，但还没做路由激活
- Routing Active（路由已激活）：路由激活成功，可以发送UDS诊断报文
- Socket Disconnected（套接字已断开）：连接关闭，回到监听状态
你想想看，为什么要有这么多状态？直接连上就干活不行吗？
不行。因为DoIP要处理多个诊断仪同时连接的情况。比如一个诊断仪在做刷写，另一个在做读取故障码。如果状态机不清晰，很容易乱套。
3.3.1 状态转换的关键事件
| 当前状态 | 触发事件 | 下一状态 | 说明 |
|---|---|---|---|
| Listen | 收到TCP连接请求 | Socket Established | TCP握手成功 |
| Socket Established | 收到路由激活请求且成功 | Routing Active | 可以开始诊断通信 |
| Routing Active | 收到关闭连接请求或超时 | Socket Disconnected | 清理资源 |
| Socket Disconnected | TCP连接完全关闭 | Listen | 回到初始状态 |
3.4 实战中的常见问题
说了这么多理论，咱们聊聊实战中我踩过的坑。
3.4.1 车辆声明报文丢失
有一次，诊断仪上电后一直收不到车辆声明报文。我抓包一看，发现网关的UDP广播被交换机过滤了。原来车载交换机的IGMP Snooping配置有问题，把广播报文当成了组播报文给过滤了。
解决方案：要么关掉IGMP Snooping，要么把车辆声明报文的目的IP改成组播地址（239.192.0.0/16）。
3.4.2 路由激活响应超时
诊断仪发送路由激活请求后，等了3秒都没收到响应。我查了一下，发现网关在处理路由激活请求时，去访问了一个很慢的外部安全模块，导致响应延迟。
解决方案：把安全认证做成异步的。先回复一个“正在处理”的中间响应，等安全认证完成后再发最终响应。
3.4.3 连接状态机卡死
有一次，诊断仪在路由激活状态下突然断网。网关的状态机没有正确处理TCP的RST（复位）报文，导致一直停留在Routing Active状态。后续的诊断仪连接请求都被拒绝了。
解决方案：在状态机里增加对TCP异常断开的处理逻辑。只要检测到TCP连接异常，立即进入Socket Disconnected状态。
好，这一章就到这里。下一章我们会讲DoIP与SOME/IP的协同工作机制，看看这两个协议怎么在同一个网络里和谐共处。