车载以太网诊断实战用Wireshark抓包解析DoIP/UDS协议附常见错误帧排查作为一名长期与汽车电子诊断打交道的工程师我深知在面对车载以太网这类新兴技术时那种既兴奋又头疼的感觉。传统的CAN总线诊断大家已经轻车熟路但当诊断通信跑在以太网上特别是面对DoIPDiagnostic communication over Internet Protocol和UDSUnified Diagnostic Services协议栈时问题排查的维度一下子从物理层、数据链路层扩展到了完整的TCP/IP网络模型。这时一个得力的网络协议分析工具就成了我们的“听诊器”而Wireshark无疑是其中最强大、最通用的一款。这篇文章我想和你分享的不是简单的软件操作手册而是如何将Wireshark这个通用工具精准地应用于车载以太网诊断这个特定场景尤其是如何解读那些令人困惑的“错误”提示比如[TCP Previous segment not captured]或[TCP Out-Of-Order]并从中找到真实问题的线索。1. 搭建车载以太网诊断抓包环境在开始解剖协议之前一个稳定可靠的抓包环境是前提。车载以太网诊断通常基于100BASE-T1或1000BASE-T1等车载专用物理层但我们的分析往往在网关或测试电脑的普通以太网口上进行。1.1 硬件连接与网络配置最常见的场景是通过一台运行诊断软件如CANoe、Vector vTESTstudio或自研工具的测试电脑连接到车辆的以太网诊断接口通常是OBD-II端口中的特定引脚。为了捕获完整的双向通信你需要将测试电脑置于通信路径中。这里有几种经典接法端口镜像SPAN如果中间使用了支持端口镜像的以太网交换机或车载网关这是最理想的方式。它将诊断口的所有流量复制一份到你的抓包端口对原始通信零干扰。共享集线器HUB在实验室环境中使用一个老式的共享式集线器非交换机连接车辆诊断口、测试电脑和抓包电脑。由于HUB是广播所有端口的因此可以捕获所有流量。但请注意HUB已非常罕见且可能影响高速通信。双网卡桥接在抓包电脑上使用两块网卡一块连接车辆一块连接测试电脑并在操作系统层面将两块网卡桥接。这种方法需要仔细配置避免引入IP地址冲突。注意绝对不要在量产车辆或关键ECU上使用可能中断通信的连接方式进行抓包尤其是在进行刷写Programming等关键操作时。实验室环境也务必先验证连接方式的可靠性。配置好硬件后需要确保抓包电脑的网卡IP地址与车辆诊断网络处于同一网段但不能与诊断仪或车辆ECU的IP地址冲突。通常车载诊断网络使用链路本地地址169.254.0.0/16或特定的私有地址段。1.2 Wireshark捕获过滤器设置启动Wireshark选择正确的网络接口后直接开始抓包可能会捕获大量无关流量如广播包、其他服务协议。使用捕获过滤器Capture Filter可以极大提升效率。针对DoIP诊断常用的过滤器有# 仅捕获与特定诊断仪或ECU IP相关的流量 host 192.168.1.100 # 捕获特定端口DoIP标准端口为13400的流量 port 13400 # 组合过滤捕获进出特定IP且端口为13400的流量 host 169.254.100.10 and port 13400 # 捕获整个诊断网段的TCP流量排除ARP等 net 169.254.0.0/16 and tcp设置好捕获过滤器后点击开始Wireshark就只会记录我们关心的数据包了。2. 从物理层到应用层逐帧解析诊断报文捕获到数据包后Wireshark的主窗口会显示报文列表。我们需要像剥洋葱一样从最外层逐层解析理解每一层协议头部的含义。2.1 以太网帧与MAC地址识别首先看最底层——数据链路层即以太网帧。在Wireshark中展开帧的“Ethernet II”部分你会看到类似下面的信息Destination: 22:34:c0:01:00:01 (22:34:c0:01:00:01) Source: e8:6a:64:20:61:3b (e8:6a:64:20:61:3b) Type: IPv4 (0x0800)目标/源MAC地址这是网卡的物理地址。在车载网络中源地址可能是你的诊断适配器MAC目标地址则是网关或目标ECU的MAC。有时你会看到多播MAC地址如以01:00:5e开头的这可能用于DoIP车辆发现等协议。类型Type0x0800代表载荷是IPv4数据包。其他常见类型还有0x0806ARP、0x86DDIPv6。这个字段告诉操作系统或交换机应该把帧交给哪个上层协议栈处理。实战技巧识别ECU。在复杂的网络拓扑中你可以通过MAC地址的前缀OUI来初步判断设备厂商。例如某些车载以太网芯片厂商有特定的OUI段。在Wireshark的“统计” - “端点”中可以清晰看到所有通信设备的MAC和IP地址对。2.2 IP帧分片、TTL与协议标识展开“Internet Protocol Version 4”层我们进入网络层。Version: 4 Header length: 20 bytes Total Length: 60 Identification: 0x105d (4189) Flags: 0x40, Don‘t fragment Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0xe217 [validation disabled] Source: 192.168.1.6 Destination: 192.168.1.8这里有几个关键字段对诊断有实际意义标识Identification与分片FragmentIP层负责将大数据包分片传输。Don‘t fragment标志置位表示该包不允许分片。如果看到分片偏移Fragment offset非零说明这是一个大诊断报文如下载软件包被分片了。在车载网络由于MTU最大传输单元通常足够大分片不常见但一旦出现乱序或丢失重组会是个问题。生存时间TTL每经过一个路由器或网关减1。在相对扁平的车载网络中TTL值通常是64或128。如果TTL异常小可能暗示报文经过了非预期的路由。协议Protocol6代表TCP这是DoIP诊断数据传输的承载协议。如果是17则是UDP用于DoIP的车辆发现和状态信息。2.3 TCP帧连接、序列与可靠性DoIP的诊断数据传递依赖于TCP的可靠连接。展开“Transmission Control Protocol”层Source Port: 13400 Destination Port: 50106 Sequence number: 13400 (relative sequence number) Acknowledgment number: 1 (relative ack number) Header length: 20 bytes Flags: 0x018 (PSH, ACK) Window size value: 64253 Checksum: 0xd153 [unverified]端口源端口13400是DoIP协议的标准服务端口。目标端口是诊断工具随机分配的高位端口。序列号与确认号这是TCP可靠性的核心。序列号指本报文段数据部分的第一个字节的编号确认号表示期望收到的下一个字节的编号。Wireshark默认显示相对序列号从0开始更易读。标志位FlagsSYN/FIN/ACK用于三次握手建立和四次挥手断开连接。PSH(Push)催促接收方尽快将数据提交给应用层如DoIP协议栈而不是缓存在TCP缓冲区。在诊断请求/响应交互中很常见。RST强制断开连接通常意味着异常。窗口大小接收方告知发送方自己还有多少缓冲区可用用于流量控制。如果窗口突然变小或为0可能表示ECU处理不过来诊断响应变慢。理解TCP流在报文列表上右键选择“追踪流” - “TCP流”Wireshark会将属于同一次TCP连接的所有报文过滤并重组并以对话形式显示应用层数据这里是DoIP/UDS这对于分析完整的诊断会话极其方便。3. 诊断协议核心DoIP与UDS报文解析现在我们抵达了应用层也就是我们工程师最关心的诊断内容。3.1 DoIP协议头解析DoIP帧是TCP载荷。在Wireshark中如果正确解码你会看到“DoIP”协议层。一个典型的诊断报文DoIP头如下DoIP Protocol Version: 0x02 Inverse DoIP Protocol Version: 0xFD Payload Type: Diagnostic message (0x8001) Payload Length: 0x00000007 Source Address: 0x0e80 (3712) Target Address: 0x0009 (9)协议版本与反码当前常见的是版本20x02。反码0xFD用于简单校验两者之和应为0xFF。载荷类型Payload Type0x8001代表这是诊断消息Diagnostic message。其他重要类型还有0x0005路由激活请求/响应这是建立逻辑连接的关键步骤。0x4001车辆识别请求/响应。0x8002/0x8003诊断消息肯定/否定响应。源地址与目标地址这是逻辑地址不同于IP或MAC地址。源地址是发送诊断请求的工具地址如0x0E80目标地址是ECU的逻辑地址如0x0009。这些地址在诊断数据库CDD/ODX中定义。载荷长度指示后面DoIP有效载荷即UDS报文的字节数。3.2 UDS服务与数据解析DoIP的载荷就是UDS报文。UDS是真正执行诊断功能的服务层协议。展开“UDS”层可能需要加载UDS解析插件或正确设置首选项Unified Diagnostic Services Diagnostic Request Service: SecurityAccess (0x27) Sub-function: requestSeed (0x01)这是一个经典的安全访问SecurityAccess0x27请求种子requestSeed报文。ECU会回复一个带种子Seed的肯定响应0x67 01 [Seed]诊断工具再用特定算法计算密钥Key发送回去0x27 02 [Key]完成解锁。其他常见UDS服务包括服务ID服务名主要功能0x10DiagnosticSessionControl切换诊断会话默认、扩展、编程等0x22ReadDataByIdentifier读取数据如VIN、软件版本0x2EWriteDataByIdentifier写入数据0x31RoutineControl执行例程如重置、自检0x3ETesterPresent保持诊断会话激活0x85ControlDTCSetting控制DTC存储在Wireshark中你可以设置过滤器doip.payload_type 0x8001 uds来只看诊断请求/响应流并结合“追踪TCP流”功能清晰地看到一次完整的诊断服务交互过程。4. 实战排查解码Wireshark的“错误”与“警告”这是最能体现工程师经验的部分。Wireshark的“Info”列经常会出现一些带[ ]的提示很多新手会误以为这是通信错误。实际上它们大多是Wireshark基于捕获到的报文序列做出的分析提示需要结合上下文判断。4.1[TCP Previous segment not captured]这个提示非常常见。它意味着Wireshark发现当前TCP报文的序列号与它期望的上一个报文序列号不连续中间有数据缺失。但这不一定代表网络丢包可能原因一抓包起点问题。如果你在TCP连接建立或数据传输中途才开始抓包自然抓不到之前的报文。这是最常见的原因可以忽略。可能原因二真实的网络丢包。如果后续看到了[TCP Retransmission]重传包且其序列号正好填补了缺失的段那就证实了中间确实发生了丢包。在车载网络中这可能由电磁干扰、线缆故障或ECU处理能力不足导致。排查方法检查该TCP流中在出现此提示的报文之前是否有握手过程。如果没有很可能是抓包起点问题。观察后续是否有重传包。如果有关注重传发生的频率和时机是否与某些大流量操作如刷写相关。在Wireshark的“分析” - “专家信息”中可以汇总查看所有此类事件评估其严重性。4.2[TCP Out-Of-Order]与[TCP Fast Retransmission]TCP乱序Wireshark发现收到的TCP报文序列号不是严格递增的。在IP网络报文经由不同路径可能产生乱序。车载以太网内部网络路径简单乱序较少见。如果频繁出现需检查网络拓扑或交换机配置。TCP快速重传这是TCP的一种拥塞控制机制。当接收方连续收到3个重复的ACK[TCP Dup ACK ...]发送方就会不等超时立刻重传疑似丢失的包。这是一个明确的丢包信号。关联分析案例 假设你看到这样的序列Packet 100: Seq1000, Len100 Packet 101: Seq1100, Len100 Packet 102: [TCP Dup ACK 100#1] // 期待Seq1200但收到了1300于是重复确认100 Packet 103: Seq1300, Len100 // 乱序到达 Packet 104: [TCP Dup ACK 100#2] // 再次重复确认 Packet 105: Seq1200, Len100 // 缺失的包终于到达可能是重传 Packet 106: [TCP Fast Retransmission] Seq1200, Len100 // 发送方触发快速重传这个案例中Seq1200的包发生了延迟或乱序接收方通过重复ACK告知发送方最终触发了快速重传。即使原始包Packet 105最终到达重传包Packet 106也已经发出。这会造成短暂的性能下降。4.3[TCP Retransmission]与[TCP Spurious Retransmission]重传发送方在超时后仍未收到确认于是重新发送数据包。这是最经典的可靠性保障机制但也意味着至少经历了一个RTT往返时间的超时对诊断响应时间有直接影响。虚假重传Wireshark判断一个重传包是“虚假”的因为它在重传之前已经看到了原始包的ACK。这通常是由于网络延迟延迟ACK或延迟数据包导致发送方误判超时。在车载网络延迟较低的环境中虚假重传较少一旦出现需关注网络稳定性。排查性能问题在“统计” - “TCP流图形” - “时间序列Stevens”中可以直观看到序列号随时间增长的情况。重传和乱序会表现为图形的回退或锯齿是分析吞吐量和稳定性的利器。5. 高级技巧与自定义分析掌握了基础解析和错误排查后一些高级功能能让你的分析工作事半功倍。5.1 使用显示过滤器精准定位问题捕获过滤器用于抓包前而显示过滤器用于抓包后筛选。结合协议字段可以构建非常强大的过滤器# 查找所有包含否定响应码NRC的UDS响应 uds.nrc and uds.nrc ! 0x00 # 查找安全访问服务的所有通信 uds.service 0x27 # 查找从特定ECU逻辑地址0x0E80发出的所有诊断消息 doip.source_address 0x0e80 doip.payload_type 0x8001 # 查找所有TCP重传的包 tcp.analysis.retransmission # 组合查找在诊断消息中查找重传包 doip.payload_type 0x8001 tcp.analysis.retransmission你可以将常用的显示过滤器保存为按钮一键切换。5.2 编写Lua插件解析自定义协议有时OEM或供应商会在标准DoIP/UDS之上定义私有协议或数据格式。Wireshark的Lua接口允许你编写自定义解析器。例如假设在UDS响应后跟随着一段自定义的厂商数据你可以创建一个简单的解析器来高亮显示它-- 保存为 custom_proto.lua 并放入Wireshark插件目录 do local p_custom_data Proto(CustomData, Vendor Custom Data after UDS) local f_vendor_field ProtoField.uint32(customdata.value, Vendor Value, base.HEX) p_custom_data.fields { f_vendor_field } local uds_dissector Dissector.get(uds) function p_custom_data.dissector(tvbuf, pktinfo, root) -- 假设自定义数据紧跟在UDS报文后长度为4字节 local offset 0 -- 先调用UDS解析器 offset uds_dissector:call(tvbuf, pktinfo, root) -- 如果还有数据且长度4则解析为自定义字段 if tvbuf:len() - offset 4 then local subtree root:add(p_custom_data, tvbuf:range(offset, 4)) subtree:add(f_vendor_field, tvbuf:range(offset, 4)) offset offset 4 end return offset end -- 将其注册为TCP 13400端口上DoIP诊断消息0x8001载荷的解析器 -- 这需要更精确的判断此处仅为示例逻辑 DissectorTable.get(doip.payload_type):add(0x8001, p_custom_data) end5.3 统计与图表化分析Wireshark的统计功能非常强大端点Endpoints查看所有通信的IP/MAC地址对快速发现未知设备或异常连接。对话Conversations查看任意两个端点之间的流量统计找出数据量最大或连接数最多的对话。协议分级Protocol Hierarchy直观看到各层协议流量占比确认诊断流量是否主导。IO图表IO Graphs绘制流量随时间变化的曲线。你可以添加过滤器例如只显示tcp.analysis.retransmission的图形来观察重传发生的具体时间点是否与某些特定操作如开始刷写强相关。在我处理过的一个疑难案例中诊断仪偶尔会报超时错误。通过IO图表我发现每当诊断工具发送一个较大的ReadDataByIdentifier0x22请求时重传图表就会出现一个尖峰。进一步分析发现是ECU的TCP接收缓冲区设置过小导致窗口满触发了丢包和重传。将问题定位到ECU配置后修改参数便得以解决。这种从应用层现象追溯到传输层乃至系统配置的能力正是深入协议分析的价值所在。