车载以太网测试中，有一条是测试DUT设备的MTU大小，下面我们来看下如何测试，以及测试中遇到的问题分析

假设需求文档里规定：DUT的以太网网卡的MTU是1500

我们先看方案，然后分析为什么这样做

通过Converter测试MTU

硬件环境

pc和dut作为通信双方，converter作为连接pc和dut的转接板

测试步骤

首先给pc的本地网卡配置一个ip地址，网段和dut在同一个网段内

然后在pc上打开一个wireshark，同时监视pc的本地网卡

最后在pc上打开cmd窗口，输入命令

ping 192.168.1.20 -l 1473  

在wireshark上查看抓取的包

分析

ping 192.168.1.20我们知道，后面的"-l 1473"呢？

它表示给192.168.1.20的主机发icmp request报文，且这个报文的icmp payload大小为1473字节

这条icmp request报文的icmp payload为1473，icmp header为8，ip header为20，那么这条报文的二层data为1473+8+20 = 1501

通常pc的网卡MTU为1500，那么这条报文想要发出去，必须要在网络层分片后发出，分成两条报文，第一条报文的二层data为ip header (20) + ip payload(1480)为1500，第二条报文的二层data为ip header(20) + ip payload(1)为21

现在我们看下在wireshark上抓取的icmp request

有两条报文：

第一条报文的长度是1514，它其实把二层头部的14个字节（这里不包括FCS校验和）也加上去了，14+1500=1514

第二条报文的长度是35，它也把二层头部的14个字节加上去（这里不包括FCS校验和），14+21=35

这两条报文到达dut后，dut的网卡MTU如果为1500，则这两条报文都可以收到，收到后会在协议栈内部先组装成一条完整的icmp报文，拿到icmp payload数据为1473

然后把这1473个字节的数据当做icmp response的payload，发回给pc

这条icmp response报文的二层data为ip header(20) + icmp header(8) + icmp payload(1473) = 1501

如果dut的MTU为1500，就只能分片发出去，同样也是分成两条报文

第一条报文的长度是1514，它其实把二层头部的14个字节也加上去了（这里不包括FCS校验和），14+1500=1514

第二条报文的长度按道理来说应该是35，它把二层头部的14个字节加上去（这里不包括FCS校验和），14+21=35

但实际上我们发现

第二条报文的长度是60，为什么？

以太网帧的data最小长度必须为46，以保证一条以太网帧的帧长至少为64（这里把FCS的4个字节算进来了）

所以icmp response分片后的第二条以太网帧虽然只有35个字节，但是为了保证帧长至少64(包括FCS的4个字节)，填充了大量的0x00个字节

所以就在wireshark上看到第二个帧长为60(没有算FCS的4个字节)
等一等，那为什么pc在发icmp request时分片的第二个帧的长度为35呢？

我猜测可能是pc系统的协议栈没有这个最小帧长的规定

我在wireshark上分析icmp response的第二条帧时还发现，当我把icmp协议层展开后发现

明明帧长只有60，为什么会显示icmp data有1473？

这里其实是wireshark为了方便使用者而自动把完整的icmp response报文内容显示了出来而已，所以千万不能通过这种方式分析报文长度

现在你应该明白如何测试MTU了吧

进一步分析

上面的方式其实是利用dut报文从网卡发出时如果帧data大于MTU需要分片的特点

而dut如何生成的这条报文？

则是由pc给dut发了一条icmp request，使得dut自动回复了同样长度的icmp response

如果pc的MTU小于1500，比如说1400，我不能发送一条帧data小于1500的icmp request，由于小于dut的MTU是1500，这样的icmp request可以收到并回复，且没有分片，根本无法确定dut的MTU大小

如果是一条帧data大于1500的icmp request呢？由于pc的MTU是1400，会分成两个分片包发出去，而dut由于MTU是1500，可以很顺利地接收到，接收后再发一条帧长大于1500的icmp response，dut的MTU是1500，又要分成帧data为1500和剩余大小的两个分片包发出去，但是，由于pc的MTU只有1400，第一个分片包无法被pc获取，也就无法确定dut的MTU大小了

如果pc的MTU大于1500呢？更加不行了，大于1500的icmp request都不能通过dut的网卡，更不要谈回复icmp response了

所以利用dut的报文从网卡发出时需要受到MTU限制而分片的特点来测试dut的MTU大小，pc的MTU必须和dut的MTU相等

既然我们可以利用MTU对于发出的报文长度有限制的特点，是否也能利用MTU对接收到的报文长度也有限制这个特点，去测试MTU呢？

也是可以的

我们只要把pc的MTU设的足够大（比dut大），然后我们从帧长较小的icmp request发起，收到icmp response后，继续把icmp request帧长加1，发出去，这样当出现某一条icmp request没有回复icmp response时，说明是被dut的MTU限制了，我们通过计算这条icmp request的帧data来计算dut的MTU大小

这也是我们接下来要讲的另一种方案

通过CANoe测试MTU

---

更多内容，请关注汽车网络诊断通信