车载以太网DoIP诊断实战：Wireshark抓包分析UDS报文全流程

做车载诊断的这几年，我最大的感受是：诊断通道正从CAN全面转向车载以太网。过去车载诊断的标准流程是诊断仪插OBD口，走CAN收发UDS报文，一套CANoe脚本就能搞定；到了新一代电子电气架构，域控制器、智能座舱、自动驾驶相关的ECU都开始挂载车载以太网节点，诊断方式变成了DoIP（Diagnostic over IP）+ UDS，抓包工具也换成了Wireshark。这篇文章不是堆概念，而是从我实际做DoIP诊断测试的视角，把Wireshark抓包分析TCP/UDS报文的完整过程捋一遍：DoIP协议栈怎么分层、TCP和UDP在诊断里分别承担什么活、从车辆发现到路由激活再到UDS响应每一步报文长什么样、以及在项目里踩过的坑怎么排查。适合正在做车载以太网测试、ECU诊断开发，或者刚入门想搞懂DoIP报文到底怎么读的朋友。

1. 从CAN到车载以太网：DoIP到底解决什么问题

1.1 传统CAN诊断的瓶颈

为什么非要从CAN诊断挪到DoIP？一句话：CAN不够用了。传统CAN诊断走的是CAN和CAN FD，物理层就是OBD口的CAN收发器，诊断协议栈是ISO 15765（UDS over CAN）。CAN的常见速率是500kbps，CAN FD最高能到8Mbps，听起来好像还行，但真到了整车量产调试、软件刷写、大数据采集场合，这个带宽根本顶不住。

我举个实际场景：给一个域控制器刷写Flash固件，固件几十MB很常见。CAN FD一个数据帧撑死也就64字节，但刷新流程里并不是每个帧都塞满，还要考虑流控、等待时间、传输层分包，实际有效吞吐经常打折。用CAN刷这种大固件，一次刷写半小时甚至更久一点儿都不夸张。还有一个场景是读DTC快照、冻结帧、环境数据，这些数据量动不动几千字节，在CAN上要分成几十上百帧去拼，解析脚本麻烦，传输也慢。再加上现在的车联网远程诊断、OTA刷写、SOME/IP服务化诊断，整个方向都在往IP网络迁移，CAN诊断这种窄带通道已经被逼到墙角了。

还有一个容易被忽视的问题，CAN诊断的寻址和路由能力有限。ECU之间的诊断依赖网关路由，CAN ID的位宽就11位或29位，逻辑地址空间、路由规则都很受限。DoIP这边直接上IP地址和逻辑地址，链路天然就是网络化的，网关路由、整车组网、跨域诊断都要灵活得多。

1.2 DoIP的技术定位与标准体系

DoIP对应的标准是ISO 13400，中文常叫“道路车辆—基于IP的诊断通信”。与之配合的是ISO 14229，也就是UDS（Unified Diagnostic Services），UDS定义了诊断服务的会话层语法和功能，比如读DTC、读写数据、安全访问、刷写。DoIP解决了“UDS报文怎么在以太网上传”的问题，UDS解决了“诊断内容是什么”的问题。

这里要理清一个关键点：DoIP并不传输所有诊断数据都走TCP。它把UDP和TCP分得特别清楚。车辆发现、DoIP实体状态查询这类“寻找节点、了解现状”的操作，走UDP，因为UDP天然支持广播和组播，一次发出，全网都能收到。真正的UDS诊断消息，走TCP，因为TCP可靠、有序、长连接，能保证诊断命令和响应不错序、不丢包。DoIP的标准端口是13400，TCP和UDP都会用到这个端口。

很多人第一次看DoIP抓包会懵，就是因为没建立起“什么时候用UDP、什么时候用TCP”的概念。记住一句话：找车用UDP，修车用TCP。后面所有报文分析都绕不开这个思路。

1.3 DoIP给诊断工作方式带来的实际改变

DoIP上车之后，诊断工作方式发生了几个肉眼可见的变化。

首先是速度和吞吐量。现在的车载以太网普遍是100BASE-T1起步，高端平台开始上1000BASE-T1，带宽相对CAN是数量级的提升。刷写固件、读取大量故障数据、标定数据采集，时间直接从“小时级”变成“分钟级”，产线调试和售后诊断效率提升非常明显。

其次是长连接带来了持续诊断的可能。CAN诊断通常是短平快，连上、发请求、收响应、断开。DoIP是基于TCP的，TCP本身维护连接状态，DoIP还有Alive Check保活机制，可以让诊断仪和ECU保持稳定长连接，持续监控、连续采集、反复读写。这种能力是CAN诊断时代很难做到的。

第三是支持远程和整车主网诊断。DoIP跑在IP网络上，天然可以和以太网、无线网络、云端平台打通。远程诊断、整车级DTC汇总、OTA升级的所有前置检查和后置验证，都可以直接复用IP基础设施。

2. 抓包前必须搞懂的三件事：协议栈、报文类型与过滤方法

2.1 DoIP协议栈的分层结构

先建立层次感。一个完整的DoIP诊断报文，从网线到Wireshark的呈现，经过的层次大概是这样：

• 物理层和数据链路层：车载以太网常用100BASE-T1或1000BASE-T1，物理层采用BroadR-Reach这类技术，一对双绞线搞定收发。链路层还是常见以太网帧，MAC地址、EtherType。如果是VLAN场景，以太网帧里会带802.1Q Tag，VLAN ID用于细分网络，优先级字段用于保证诊断报文的高QoS。
• 网络层：IPv4主导，部分新平台开始考虑IPv6。DoIP的IP层内容不复杂，但要注意分片和TTL等细节。
• 传输层：TCP和UDP同时在用。UDP负责车辆发现、状态查询；TCP负责路由激活和诊断消息。端口都是13400。
• 应用协议层：DoIP头 + UDS数据。DoIP头固定8字节，控制着整个报文的帧类型、payload长度，UDS数据才是真正干活的。

在Wireshark里，抓到一个包之后，面板上会依次展开Ethernet II、IPv4、TCP/UDP、DoIP、UDS（如果解析出来）。不要一上来就找UDS字节，先学会“剥洋葱”一样从底层往上看，这样才能定位问题到底出现在哪一层。

2.2 DoIP关键报文类型速查

DoIP的报文类型通过DoIP头里的Payload Type字段区分，两字节。我平时抓包最常遇到的类型就那十几种，整理成一个表方便对照：

这里有个地方特别容易困惑：诊断消息的Payload Type有时候显示0x8001，有时候显示0x4001。我在不同工具、不同Wireshark版本里都见过。实际上这是ISO 13400-2版本演进带来的差异，旧版本定义是0x4001到0x4004，新版本规范做了调整，部分实现使用0x8001系列。遇到这种显示差异，不用慌，看Wireshark解析出来的DoIP字段，或者自己按DoIP头格式手动解析，逻辑完全一致。

2.3 Wireshark环境准备与抓包基本操作

Wireshark的安装本身没什么难度，但有几个细节会影响DoIP抓包质量。

第一，版本尽量选新的，4.0以上对DoIP的解析已经做得相当完整，可以自动识别DoIP头，甚至能把UDS数据解析出来。老版本可能要做一堆手动解析，效率差很多。Windows下安装时记得勾选Npcap，这是抓包依赖的底层驱动。Linux/Mac下需要确保有权限访问网络接口。

第二，抓包前选对网卡。连接到车载以太网测试设备后，Wireshark主界面会出现对应的网络接口，比如USB转以太网适配器、Vector/VN系列、Pico汽车以太网套件等对应接口。选中接口后要确认“启用混杂模式”打开，否则可能只能看到发给本机的广播包和组播包，单播诊断报文会漏掉。

第三，过滤策略。抓包过滤器和显示过滤器是两码事，很多初学者混着用导致抓包性能很差或者抓到一堆无关数据。如果做DoIP专项抓包，抓包过滤直接写：

tcp port 13400 or udp port 13400

这样在链路层就把非13400端口的流量丢掉，既减小文件体积，又能保护性能。显示过滤则是抓完之后在分析界面上用，比如只显示DoIP协议、只显示某个ECU地址的报文，后面的实战里我会具体举例。

还有一个值得提前做的设置：长时间抓包时，在“捕获选项”里开启多文件模式，比如每个文件100MB，环形缓冲覆盖旧文件，防止时间和内存被大文件拖垮。这个在做夜间稳定性测试、长时间运行诊断脚本时特别有用。

3. 实战全流程拆解：从车辆发现到UDS响应

3.1 车辆发现阶段（UDP上的0x0001与0x0004）

DoIP诊断的第一步不是直接连TCP，而是先在网络里找到设备。Tester会发送一个Vehicle Identification Request，也就是0x0001报文，目标IP通常是广播地址255.255.255.255，或者指定的组播地址，UDP端口是13400。这个报文整个网络里的DoIP实体都能收到。

请求发出后，支持DoIP的ECU或网关会返回Vehicle Identification Response，也就是0x0004报文。这个响应里包含非常关键的信息：VIN码、DoIP实体的逻辑地址、EID（实体的唯一标识）、GID（组标识）等。在Wireshark里看这个报文，重点看VIN字段和Logical Address字段，VIN能帮你确认当前抓到的是不是目标车辆，Logical Address则是后续UDS报文中目标地址的判断依据。

还有一种情况是ECU上电后主动发送广播通知，报文类型同样是0x0004，但没有对应的0x0001请求。这是DoIP实体“主动上线”的宣告，Wireshark里看起来就是一个孤立的Vehicle Identification Response，别把它当成异常包，这正是车辆角色在告诉你“我上线了，可以找我做诊断”。

3.2 TCP三次握手：诊断连接的建立

车辆发现做完，接下来就是TCP连接。目标IP就是刚才车辆发现阶段拿到的DoIP实体IP，目标端口13400。

TCP握手的过程大家应该都熟：SYN、SYN+ACK、ACK。但在DoIP场景里，我建议大家不要太快划过这个阶段，多看几个细节。

第一，看SYN包里的选项。窗口大小、MSS、SACK许可这些TCP选项，能反映当前链路是否存在限制。车载以太网有时跨越网关或经过交换机，虽然带宽大，但如果有QoS配置、VLAN优先级设置，TCP参数也可能受到影响。

第二，看是否有重传、快速重传、重复ACK、零窗口这类TCP异常。我实际遇到过好几次：UDS层面一直超时，排查到最后，问题根本不在DoIP，而是TCP层在一直重传，底层链路丢包严重。这个经验真的很重要，如果你在Wireshark里看到大量TCP Retransmission，先别急着分析UDS内容，TCP都穿不过去，UDS怎么可能通。

第三，三次握手完成后，TCP进入Established状态，后续的DoIP报文都在同一条TCP流里。Wireshark里可以右键任意包，选择“追踪TCP流”，把整条流的交互顺序看一遍，这个操作在分析诊断事务时非常高效。

3.3 路由激活：Tester向DoIP实体注册

TCP连上之后，很多人会以为“连上了就能发UDS”，但实际不行。DoIP协议里还有一个强制前置步骤：路由激活，也就是Routing Activation Request，类型0x0005。

Tester发送0x0005报文，里面带着Tester自己的逻辑地址，以及激活类型。DoIP实体收到后，会判断这个Tester是否合法、是否允许接入，然后返回0x0006 Routing Activation Response。这个响应里会包含激活状态码：成功、拒绝、未知目标地址、不支持的激活类型等等。只有收到成功的激活响应，TCP连接才真正被“授权”用于诊断消息传输。

我习惯把路由激活理解成“前台登记”。你进一栋大楼，TCP连接只是让你到了门口，路由激活才是让你在访客系统里登记身份、拿到临时门禁权限。没登记就去敲部门办公室的门，没人会理你。抓包时的表现就是：不发路由激活直接发0x8001诊断消息，DoIP实体会直接忽略，或者给你一个Generic NACK，UDS请求毛响应都没有。

这里还要注意一个隐蔽细节：0x0005路由激活请求里带的Tester逻辑地址，在后续所有UDS报文中都必须保持一致。有些测试工具支持配置多个逻辑地址，如果配置不当，会出现“路由激活用的地址A，诊断消息用的地址B”的混乱，结果就是ECU侧明明收到了报文，却因为地址不对而丢弃。

3.4 核心重头戏：UDS诊断报文的逐字节解析

完成路由激活后，终于可以发UDS诊断消息了。我拿一个最典型的场景演示：读DTC列表。

假设Tester逻辑地址是0x0F00，ECU逻辑地址是0x0A01（实际地址以厂商诊断规范为准，这里只是例子）。UDS命令是0x19 02 FF，含义是“按状态掩码FF读取DTC”。整条DoIP诊断消息封装如下：

02 FD 80 01 00 00 00 07 0F 00 0A 01 19 02 FF

这段十六进制逐字节拆开是这样的：

• 02：DoIP协议版本号，ISO 13400-2当前版本就是0x02。
• FD：版本反码，0x02取反后是0xFD，用来校验版本字段是否正确。
• 80 01：Payload Type，0x8001，代表这是TCP上的DoIP诊断消息。
• 00 00 00 07：Payload Length，4字节大端整数。这里等于7，表示后面跟着的payload是7个字节。
• 0F 00：Tester的源逻辑地址。
• 0A 01：目标ECU的逻辑地址。
• 19 02 FF：UDS数据，SID是0x19，子功能是0x02，状态掩码是0xFF。

所以DoIP的封装规律很清楚：8字节DoIP头，之后是2字节源地址、2字节目标地址，最后才是真正的UDS数据。不管请求还是响应，这个结构都不变，只是源地址和目标地址会互换。

如果要在自动化脚本里构造这样一个请求，核心代码很简单：

import socket tester_addr = 0x0F00 ecu_addr = 0x0A01 uds_cmd = bytes([0x19, 0x02, 0xFF]) # DoIP payload = 源地址 + 目标地址 + UDS数据 payload = tester_addr.to_bytes(2, 'big') + ecu_addr.to_bytes(2, 'big') + uds_cmd # DoIP header = 版本 + 反码 + PayloadType + PayloadLength doip_header = bytes([0x02, 0xFD]) + (0x8001).to_bytes(2, 'big') + len(payload).to_bytes(4, 'big') frame = doip_header + payload s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('192.168.1.10', 13400)) # 注意：实际诊断流程里前面还要先做路由激活，这里只演示报文封装 s.send(frame) resp = s.recv(4096) print(resp.hex())

ECU正确读完这条消息后，正响应的UDS部分是以0x59开头（0x19 + 0x40），然后是子功能0x02、DTC状态掩码、DTC数量，再往后是DTC号和状态字节。整条响应同样被包在正常的DoIP头里。这里要注意，DoIP层面可能还会先回一个0x8003诊断消息确认报文，表示“我收到了”，真正的UDS正响应后面才到。不要把Ack当成UDS响应。

如果请求本身有问题，ECU回的是负响应，UDS部分以0x7F开头，结构是7F + SID + NRC。比如ECU不支持0x19服务，会回7F 19 11，NRC是0x11，表示serviceNotSupported。再比如0x19请求里忘了带状态掩码，长度不够，可能回7F 19 13，NRC 0x13表示报文长度或格式错误。看到7F不要慌，先看NRC，再回查请求格式。

3.5 常见UDS服务与负响应速查

做DoIP诊断分析，UDS层面的服务不可能绕开。我把自己最常用的服务整理成一个速查表：

负响应码更是排查问题的关键入口。我遇到的频率从高到低排个序：

遇到UDS超时或者NRC异常，最忌讳的是“瞎试”。先确认会话状态，再确认安全访问状态，再确认报文长度和格式，最后确认DID/服务是否在当前车型支持。顺序不能乱。

4. 常见问题排查与避坑指南

4.1 抓不到包或DoIP解析不出来

这是新人最常遇到的问题。Wireshark抓了半天，只有广播包，看不到任何DoIP单播流量，或者即使抓到了也是一堆以太网裸数据，没被解析成DoIP。

先检查硬件和网卡：确认你连接的以太网口是真实连通的车载以太网测试口，不是Wi-Fi网卡。Wi-Fi网卡在车载以太网诊断场景下基本没用，因为抓不到目标单播包或者被AP隔离掉。如果是通过交换机镜像口抓包，确认镜像方向是双向的，否则只能看到一个方向的报文。

再检查混杂模式。Windows下Npcap如果没正确安装，或者抓包软件没有以管理员权限运行，混杂模式可能无法生效。我踩过最蠢的一次坑，就是抓包时忘了开混杂模式，单播诊断报文一个都看不到，白白排查了一个多小时。

如果报文能抓到、但Wireshark没识别成DoIP协议，大概率是Wireshark版本太老，或者DoIP heuristic解析没有启用。在协议偏好里找到DoIP，勾选“Try heuristic subdissector”，让Wireshark尝试自动识别DoIP头。另外注意：如果诊断流量带了VLAN Tag，有些普通PC网卡和抓包驱动会直接丢弃VLAN帧，这时候需要换支持VLAN透传的网卡，或者在交换机镜像口把Tag处理好再送进来。

4.2 TCP连接失败与端口占用

TCP连接建立失败，最常见的原因是13400端口被其他进程占了。做DoIP测试时，测试工具、自己写的脚本、其他诊断软件可能同时抢占这个端口。

Windows下查端口占用：

netstat -ano | findstr 13400

Linux下用：

ss -tlnp | grep 13400

找到占用进程后，杀掉旧进程或者改掉旧工具的端口配置，就能解决。还有一种情况是防火墙拦截了13400端口。Windows防火墙、Linux iptables/firewalld都可能会拦，测试时先确认防火墙规则放行了TCP和UDP的13400端口。

另外，即使TCP端口没被占，也可能出现“TCP连上了，但DoIP实体没有任何回应”的情况。这时候去看路由激活做了没，因为TCP只是通道，路由激活才是授权。如果路由激活没完成，后续UDS请求直接石沉大海，连个NACK都没有。

4.3 UDS响应超时与NRC原因定位

UDS请求发出后，如果一直等不到响应，或者收到7F负响应，按这个顺序排查最省时间。

第一，确认报文长度。0x13错误多数是长度问题。比如0x22按DID读数据，DID是2字节，请求应该是22 + DID_High + DID_Low，如果少写一个字节，ECU直接NRC 0x13。

第二，确认会话状态。很多服务只在扩展会话或编程会话下才支持。默认会话下请求写数据、刷写，ECU会回0x22（条件不正确）。这个层级问题是最常见的，尤其是在远程诊断场景，Tester连接上来之后默认停在默认会话，得先发0x10 03切到扩展会话才能继续操作。

第三，确认安全访问。需要解锁的服务，比如0x2E写数据、0x36传输数据，如果没有先做0x27安全访问，NRC大概率是0x33。安全访问还要注意算法是否匹配，种子和密钥的生成逻辑是OEM或者ECU供应商逼着定，错了就继续0x35或0x36。

第四，确认DID和服务支持范围。请求的DID在目标ECU上不存在，NRC是0x31。这个只能靠诊断规范文档逐个核对，没有捷径。

第五，注意0x78。responsePending表示ECU正在处理，比如Flash擦除耗时较长，ECU会先回一个0x78让Tester不要超时，过一会再回真正的正响应或负响应。如果Tester把0x78当成错误处理，反而会把一个正常的耗时操作搞成超时失败。

4.4 长连接、保活与超时处理

DoIP是一个典型的长连接场景。TCP连接建立并完成路由激活后，这个连接会一直保持，除非有一方主动断开或者长时间无活动。

DoIP协议里专门有Alive Check机制。DoIP实体会定期发送0x0007 Alive Check Request，要求Tester回应0x0008 Alive Check Response。如果Tester没有及时回应，DoIP实体会认为这个Tester已经离线，把对应的路由注销，后续UDS请求就不处理了。

做自动化诊断测试时，这个机制特别容易踩坑。脚本如果只是“发请求等响应”，长时间不发任何数据，连接可能被DoIP实体判定为超时断开。解决办法是在框架里定时处理Alive Check请求，确保每次收到0x0007都能自动回0x0008。我在Wireshark里就看到过很多次“Tester一直发UDS但无响应”的案例，追到底就是Alive Check没回，路由早被注销了。

抓包时看Alive Check也很有价值。你可以通过0x0007的频率判断DoIP实体的保活策略，如果测试中连接总是莫名断开，看看是不是保活响应延迟导致。

5. 实测心得与进阶建议

5.1 提升Wireshark抓包效率的几个实用技巧

做DoIP分析，最强调“高效”。分享几个我自己长期在用的技巧。

第一，自定义列。默认的Wireshark列信息对DoIP分析不够直观。我习惯把doip.payload_type、doip.srcaddr、doip.dstaddr、tcp.stream加进列显示，这样一屏就能看出当前报文的帧类型、源地址、目标地址和TCP流编号，不用点开每个包。

第二，善用“追踪TCP流”。右键任意一个诊断报文，选择“追踪TCP流”，就能看到整条连接上的完整交互：TCP握手、路由激活、UDS请求、UDS响应。对单设备调试来说，这是最高效的问题定位手段。

第三，过滤表达式要记几个常用的：

doip doip.payload_type == 0x8001 doip.srcaddr == 0x0f00 or doip.dstaddr == 0x0f00 tcp.port == 13400 && tcp.flags.syn == 1

注意Wireshark显示过滤器里十六进制要写0x8001这样的格式，不然容易被当成十进制，结果永远匹配不出来。

第四，长时间抓包一定要用捕获过滤器，不要只用显示过滤器。显示过滤器只是“藏起来”，抓包流量还是全部进了内存。捕获过滤器在源头就把无关流量丢掉，长时间跑稳定性测试时，文件小、CPU占用低。

第五，抓完包先看Expert Info。Wireshark的“Expert Information”面板会汇总所有重传、丢包、错误标记，比你在报文列表里肉眼翻高效得多。TCP层的问题，在这个面板里一眼就能扫出来。

5.2 从DoIP到SOME/IP与SOA诊断的演进

DoIP是整个车载以太网诊断的基石，但现在的新架构里，已经不只是单纯DoIP这么简单了。

比如SOME/IP，SOME/IP是基于IP的服务中间件，很多域控之间的服务发现、服务调用都基于它。诊断服务也可以被封装成SOME/IP服务，Tester通过SOME/IP调用诊断服务接口，底层再转发为UDS over DoIP或者其他诊断路由。Wireshark对SOME/IP的解析也支持得不错，但如果你连DoIP都还搞不清楚，看SOME/IP只会更晕。

我比较建议的学习路径是：先把UDS over DoIP抓包分析练熟，把TCP、UDP、逻辑地址、路由激活、DTC读取跑通，再去看SOME/IP服务发现、事件通知、远程调用。地基打牢之后，上层就是一层窗户纸。

5.3 学习路径与工具链推荐

接触DoIP诊断，你的实验环境至少要能“发真包、抓真包、读真包”。

如果公司有VectorVN5640、VN5610这类汽车以太网接口卡，配合CANoe的DoIP Option，是最省事的方案。Vector工具链对DoIP的支持非常成熟，可以直接模拟Tester、自动路由激活、自动处理Alive Check。缺点是贵，个人学习阶段很难拿到。

如果只是自学入门，我更推荐纯软件方案：自己写一个简单的Python脚本模拟DoIP Tester，在本地或虚拟网卡上连接一个开源DoIP模拟器，再用Wireshark抓包。这样虽然看不到物理层和100BASE-T1的细节，但DoIP头、TCP握手、路由激活、UDS请求响应这些核心逻辑都能完整走一遍。我自己带新人时，经常先让他们用这种方式跑通全流程，再上真车台架。

另外，OLED屏的Pico汽车以太网套件、周立功的部分以太网分析仪也是高性价比的选择，支持100BASE-T1抓包和Wireshark接入，适合个人和小团队。

最后说点个人体会。刚开始做DoIP测试时，我最容易犯的错是拿到报文就直接看UDS字节，把DoIP头当成冗余信息跳过。后来吃过亏才明白，DoIP头里每一个字段都值得看，特别是Payload Length和源/目标逻辑地址，这些字段一旦不对，后面整条链路都会出问题。踩过几次坑之后，我现在做DoIP抓包都有一套固定流程：先看车辆发现，再看TCP握手，再看路由激活，最后才分析UDS内容，虽然慢，但稳。这套流程也分享给你。如果大家在实际抓包中遇到奇怪的报文，欢迎一起交流，我可以把常见现象再整理一份出来。