2.4 报文抓包解析实验

2.4 报文抓包解析实验

本节摘要：用一个仿真从站加抓包工具完成一次完整实验——截获正常问答、异常响应与超时重试三类报文，逐字节读出含义。实验方法可直接复用到任何现场，是排错能力的基本功。

实验准备

实验环境只需要三样东西：一个 Modbus 从站仿真器（开源的协议仿真软件很多，任选其一）、一个主站测试工具（串口调试助手加手动组帧脚本，或图形化主站工具）、一个抓包观察窗口。串行链路的观察用带总线监听功能的串口工具，或者干脆用两台电脑——一台做主站，一台开仿真器，中间的 USB 转串口线用监听工具旁路观察。以太网链路更简单，主站与仿真器都开在本机，抓包软件过滤 502 端口即可看到全部往返。

实验目标定为三个，对应三种典型报文：捕获一次正常的读保持寄存器问答；故意构造一个越界请求，捕获异常响应；把仿真器响应延时调大，观察主站超时与重试行为。三个实验做完，2.1 到 2.3 的所有规则你都在字节层面见过实物了。

学习目标

阅读完本节，你应当能够：

1. 搭起一套零硬件成本的抓包实验环境；
2. 逐字节解读正常问答帧、异常帧，并验证 CRC；
3. 通过实验观察超时重试与帧间静默的真实时序；
4. 把同一套方法迁移到现场的总线监听与以太网抓包。

一、实验一：逐字节解剖一次正常问答

主站发起请求：读 3 号从站保持寄存器，偏移 100 起 2 个。仿真器预设 400101 区的值为 2500 与 800。抓包窗口截获两个方向的数据如下：

方向：主站 -> 从站
01 03 00 64 00 02 C5 DA

拆解：
01    从站地址（点表 3 号从站是举例，这里用 1 号更贴近默认配置）
03    功能码：读保持寄存器
00 64 偏移 100，即点表 40101
00 02 数量 2 个寄存器
C5 DA CRC-16 校验（低字节在前）

方向：从站 -> 主站
01 03 04 09 C4 03 20 D8 41

拆解：
01    地址回显
03    功能码回显
04    数据区字节数：4
09 C4 第一个寄存器，十六进制 0x09C4 = 十进制 2500
03 20 第二个寄存器，十六进制 0x0320 = 十进制 800
D8 41 CRC 校验
​

三个细节值得在实验里亲手验证。第一，CRC 低字节在前：把 C5 DA 顺序颠倒后再算校验，工具会报错——不少自制主站栽在这里。第二，响应里没有地址字段：数据从哪个寄存器来的，响应只回数据不回地址，主站靠事务顺序自己知道。第三，数值是原始字节：2500 就摆在 09 C4 两个字节里，任何"单位换算"都是点表层面的约定，协议层不参与。

验证 CRC 有个取巧办法：把截获的整帧（不含 CRC 两字节）喂给任意在线 CRC 计算器，选 CRC-16/MODBUS 多项式，得到的结果应与帧尾两字节（注意倒序）一致。这个动作做上三回，你对"校验失败"类故障就有了肌肉记忆——它们不过是链路把某些字节改了样。

二、实验二：制造并解读异常响应

把请求改成读 300 个寄存器——超过一帧能携带的上限。仿真器应答：

方向：主站 -> 从站
01 03 00 64 01 2C xx xx    （数量 0x012C 即 300，故意越界）

方向：从站 -> 主站
01 83 03 61 31

拆解：
01    地址回显
83    功能码 03 加最高位 —— 异常应答标志
03    异常码：数据非法（数量超限）
61 31 CRC
​

把异常码换成越界地址（比如偏移 65535）再试一次，得到异常码 02 地址非法。对照 2.1 的异常码表：03 与 02 都是"请求本身有问题"，主站该做的是修正请求而不是重试。许多轮询程序在这上面犯低级错误——把所有异常都当网络抖动无限重试，总线被无意义的重发淹没。实验里再加一步：故意用 06 号功能码写输入寄存器区，观察设备回 01（功能码与区域不匹配）还是 02，不同固件的选择不同，但都属于"改请求"类异常。

图8 实验报文流全景：正常、异常与超时三路

三、实验三：超时、重试与重复请求的副作用

把仿真器的响应延时调到五百毫秒，主站超时设两百毫秒。观察到的时序是：主站发请求，两百毫秒无响应，重发同一请求，仿真器收到两个相同请求后回了两个相同响应，主站以第一份响应为准，第二份丢弃。三个推论从这里自然长出来：

第一，写操作的重复请求有副作用。读操作重复执行无害，写线圈或写寄存器被执行两次，多数场景也无害（幂等），但对计数器、脉冲输出这类"每执行一次就累加"的对象，重复执行就是真实错误。因此对这类点位，主站要么把超时放宽到绝不重发，要么改用带事务号的写法。第二，超时参数的代价是双向的：设短了在慢从站上制造重复请求，设长了在真故障上拖慢恢复。第三，实验三复现了现场一大类灵异故障——"没动过参数，计数却多了"，事后抓包一看，链路质量差导致重发，重发命中了非幂等点位。先有实验里的直觉，现场遇到时才会往这个方向想。

四、迁移到现场的方法差异

实验环境与现场有两个重要差异，方法上要相应调整。其一，现场串行总线通常不允许你插入监听设备——带电接入监听器可能改变总线电气特性。可行的替代是利用主站软件自带的报文日志功能，多数商用 SCADA 与网关都能输出原始帧日志；拿不到帧日志时，退而求其次分析应用层日志与从站响应延时统计。其二，现场以太网抓包要选对位置：在交换机上做端口镜像，或者直接抓网关设备本机，别在旁路抓——交换机不把别人的帧发给你的网卡，旁路什么都看不到。

💡 关键直觉：抓包解析的价值不在"能看到字节"，而在"能把争议变成证据"。设备厂商说"你们主站发的就是错的"，主站厂商说"设备响应不合规"，一帧截获的报文能让争论立刻结束。养成先抓证据再开口的习惯，集成项目的扯皮会少一大半。

五、实验答疑

**问：仿真器和真实设备的报文会有差异吗？**帧结构层面不会——格式就是格式；行为层面会：真实设备的响应延时抖动更大、异常码的返回更"任性"（有的设备对越界请求返回 02，有的返回 04，还有的直接沉默）。这也是实验三步要走完的原因：仿真器教你读帧，真实设备教你读设备。

**问：抓包时看到一帧里功能码不是我发的，是什么情况？**优先怀疑两件事：一是总线上还有第二台主站在工作（很多老系统有手持编程器或备用主站偶尔上线），二是抓包工具的时间戳对齐问题让你把别人的帧看成了自己的。第一优先级排查：把总线上的主站设备数清点一遍——这也是 5.1 行为监控里"基线外主站告警"要防的场景，实验里见过一次，现场就认得出。

本节实验小结

• 环境三件套：仿真从站、主站工具、抓包窗口，零硬件成本即可复现全部经典报文形态；
• 正常帧三细节：CRC 低字节在前、响应不带地址、数值为原始字节无单位；
• 异常码两分法：02、03 改请求，04、06 可重试，分类决定动作；
• 重复请求有副作用：超时重发对非幂等点位是真实风险，超时参数要在快恢复与误重发之间权衡。

下一节把这些功夫用在哪？用在两个最著名的 Modbus 故障上：CRC 失败与寄存器错位。