国庆放假前几天关注了 辛吉飞 注销账号的大瓜， 飞哥只是人退出了原短视频平台， 辛吉飞 拥护者自发的转发她的历史视频，英雄不能被遗忘， 得嘞，于是整个国庆期间“ 辛吉飞 裂变”小号短视频长期霸占我的推荐页面。奇怪的是， 我也没轻易的划走，即使那条食品添加剂视频曾今看到过，心理学上怎么解释我的行为呢？

食品成分一直以来都强制厂家明明白白写在产品包装上，可惜不是每个市民都有心去一一查阅各成分的作用。

感谢海克斯科技 让市民懂得看成分表。

呀！原来都是酱油有添加剂？牛奶里面没有奶？奶香添加剂？奶茶里也没有茶叶？各种科技与恨活呀。飞哥是个很硬的男人，正面刚。

汽车科技与恨活

国庆假期酒足饭饱我也做了汽车圈里的科技与恨活，前些天不是看了TC8测试框架嘛，之后打算尝试搭建一套测试平台， 用于测试Linux TCP/IP以太网协议栈，当然所有测试用例我得自己写，国庆7天已经小有成效，完成部分UDP协议栈测试用例。

本来想着Linux协议栈不会存在任何问题，而跑起测试用例还真碰到几条Linux TCP/IP 以太网协议栈没法通过的case，这里的没通过不代表Linux TCP/IP 以太网协议栈有缺陷，几个不痛不痒的case没法覆盖。

再次吟起陆老师的诗：“纸上得来终觉浅，绝知此事要躬行”。

我不会在本文具体分析发现问题背后的基理，可能过些天会单独写文章记录吧。感兴趣的自己去阅读RFC768，RFC768对UDP的设计并没有太严格的要求。过不了的case有如下两个：

• 你能说说UDP端口如果设置成0，会发生什么情况吗？

• UDP用户区域发送20字节，UDP协议头只告知协议栈发送10字节，会发生什么？

他们都是TC8的测试用例。

测试用我仅仅完成UDP的一小部分，后面全是体力活，没有太多需要修改框架的。

如何设计TC8设计框架

根据TC8的拓扑图，定义测试控制端（TASTER）和被测设备（DUT，Device Under Test），TIface-0和DIface-0连接以太网，另一根线根据实际测试平台替换成其他通信机制，总之不能和DIface-0使用相同的协议栈。

DUT端：

• 调试线（ssh、telnet、或其他）

• tcpdump

• libpcap

• bash（或其他交互shell）

TESTER端：

• 调试线（ssh、telnet、或其他）

• expect（自动化脚本）

• tcpdump（数据包抓取工具）

• libpcap（数据包抓取库）

• libnet 以太网数据包构造，可构造任何“合规”不合规的TCP/IP协议

• bash

• unpack-pcap.elf 与wireshark相同，但可以独立分析数据包的同类型工具

• udp-build-any.elf 构造数据包，完成所有udp测试用例

看到这里有部分读者可能会抬杠，测试框架本来就为了测试以太网，DUT怎么会有ssh等以太网协议呢？先别较真，还是我上文说的，要保证DUT的两个传输线采用不同的通信协议栈，如果Control channel采用以太网你看不顺眼，完全可以换成串口、usb口、can总线。

我只是为了方便调试目前的环境，才这么写。我的环境里DUT是另一块ARM开发板。

跑起来

整个框架流程图大致如下，每个测试用例都重新走一遍。

假期我只完成部分UDP测试，相当于过程跑通了。至于其他协议ARP、ICMP、IP、UDP、DHCP我认为都能用相同的处理流程。唯独在编写TCP测试用例会麻烦点（相对于UDP_DatagramLength_05_D.elf这个文件来说），TCP有严格的顺序要求，有可能没法直接用tcpdump抓包，得自己编写依赖libpcap的逻辑，或者测试用例子添加进程通信（这个以后再说）。

下面是执行测试用例TestCase_UDP_DatagramLength_05的过程截图。

整个执行过程使用到的源码大致如下：

• 本地启动抓包，文件保持成TESTER/UDP_DatagramLength_05_T.pcap

• 启动原创操作DUT，这里以ssh为操作通道，命令DUT执行UDP_DatagramLength_05_D.sh脚本

• case-udp/UDP_DatagramLength_05_D.sh脚本启动服务器UDP_DatagramLength_05_D.elf用于接收TESTER发送的数据（其实本测试用例可以不启动任何应用层服务器，以为够着的数据包是非法的，根本传递不到应用层）

• DUT保持抓包数据到DUT/UDP_DatagramLength_05_D.pcap

• TESTER发送用udp-build-any.elf构造UDP数据包

• TESTER用unpack-pcap.elf比较两端pcap内容是否一致

精简

至于DUT有没有必要实现tcpdump和libpcap呢？

建议，如果资源充足的情况下，能移植就移植，实在不行也有曲线救国的方法。

libpcap不仅仅linux、windows有支持，rt-thread也有相同的东西，无论你用什么方法，只要能把数据保存成pcap文件格式就可以。

曲线救国方法如下：就再弄一条调试线2，单独转发镜像，DIface-0收发任何数据，都往调试线2上发送），让TESTER端从调试线2用tcpdump保存成pcap格式。