调试工业以太网设备最怕的就是现象能看见、原因抓不着。一台以太网温湿度变送器明明说明书上写着支持SNMP和Modbus TCP/IP可你从监控平台上读不到温湿度或者组态软件里寄存器一直超时。这时候把Wireshark打开、抓一遍报文问题往往一眼就能定位。这篇文章我就拿温湿度变送器这个典型场景把SNMP和Modbus TCP/IP两条协议栈在网线上的每一个字节都拆开讲从抓包环境搭起到报文结构、数据解析、故障排查全程按实际调试节奏走一遍。想真正搞懂工业协议、或者正在跟动环监控、机房环境、仓储温湿度采集项目打交道的工程师这篇文章可以直接当操作手册用。1. 抓包环境搭建一台电脑加一块网卡就够了1.1 温湿度变送器为什么要同时支持SNMP和Modbus TCP先说清楚这个场景的底层逻辑。温湿度变送器这类设备在项目里要给两拨系统供数据一拨是网络运维侧的监控平台另一拨是自动化控制侧的SCADA或组态系统。SNMP走的是UDP 161端口本质是网络管理协议用来做设备状态纳管和资产监控Modbus TCP/IP走的是TCP 502端口本质是工业数据采集协议用来周期性读取寄存器里的实时数值。一台设备同时支持两种协议栈不是厂商在堆功能而是因为它要同时服务于这两个完全不同的数据消费方。SNMP把设备当成一个网络管理对象读它的时候用的是GET请求、OID标识、MIB库这套语言Modbus TCP把设备当成一个数据寄存器表读取时用功能码加寄存器地址这套语言。你如果只会其中一种遇到对面系统联调时就容易抓瞎。我打个你容易记的比方SNMP像是给物业中心上报我这里有人住着、室温多少、门禁是否正常是管理方主动来查Modbus TCP更像是直接把水电表的数据表打开你随时过来抄数字。两类协议的报文长得完全不一样必须分开拆。1.2 抓包前的软硬件准备与抓包位置选择硬件上其实非常朴素一台带网口的PC、一根网线再把变送器供电接好。连接方式有两种一是变送器和PC直连用静态IP配上同一网段二是中间串一个小交换机用Wireshark在PC上抓全部流量。直连适合单设备调试串交换机适合现场有多台设备、要顺便看广播和冲突的情况。软件层面就去官网装最新版Wireshark。安装时有个细节要注意Windows下安装Wireshark会顺带装Npcap这个驱动是抓包的基础宁可多花两分钟把Install Npcap勾上也不要用旧版WinPcap不然在Win10/11上经常抓不到包。装完之后打开Wireshark如果能看到你网卡名字且在线基本就绪。抓包前还有一步容易忽略把PC上无关的流量压下来。Windows更新、远程桌面、杀毒软件后台扫描都会让抓包文件里堆满垃圾包。调试期间建议把设备IP固定好在同一网段比如变送器配置为192.168.1.100PC配置为192.168.1.50然后在Wireshark的捕获过滤器里提前写一条规则这一步能帮你省掉很多后续筛选时间。1.3 Wireshark过滤器语法先定一个调子Wireshark有两层过滤捕获过滤和显示过滤。捕获过滤是在抓包前就决定哪些包进内存显示过滤是抓完之后再从文件里筛选。平时我推荐宽进严出捕获过滤只限制IP和端口显示过滤再按业务场景精确筛选。推荐几组起步过滤器目的捕获过滤语法显示过滤语法只抓温湿度变送器host 192.168.1.100ip.addr 192.168.1.100只抓SNMPudp port 161udp.port 161只抓Modbus TCPtcp port 502tcp.port 502两者都要host 192.168.1.100 and (udp port 161 or tcp port 502)(ip.addr 192.168.1.100) and (udp.port 161 or tcp.port 502)显示过滤器还有一个实用技巧当你看到报文列表里某个协议被你认出来了右键该字段选择作为过滤器应用或者复制过滤器Wireshark会自动生成正确的过滤表达式。很多新人纠结为什么自己写的过滤器老报红其实就是字段名写错用这个右键复制功能可以避开所有记错字段名的问题。2. SNMP报文深度拆解UDP 161端口上的读操作全程2.1 一次完整SNMP请求与响应报文逐字节分析SNMP抓包最典型的就是一条Get请求配一条GetResponse响应。我们先看请求方向。我挑一段抓到的典型SNMPv2c报文把hex转储拆开讲。先看头部30 26 02 01 01 04 06 70 75 62 6C 69 63 A0 19 02 04 55 4A 9E 2E 02 01 00 02 01 00 30 0B 30 09 06 05 2B 06 01 04 01 ...这段怎么读30表示这是一个SEQUENCE后面26是整段长度46字节。02 01 01表示整数类型、长度1字节值为01。这里就是SNMP版本号1代表SNMPv2c如果是0就是v1版。04 06 70 75 62 6C 69 63表示字符串类型、长度6内容是public。这就是请求里带的团体名。很多设备默认读团体就是public抓包时能看到明文。A0 19 02 04 55 4A 9E 2E才是PDU核心。A0代表GetRequest-PDU后面跟着request-id也就是请求序号0x554A9E2E。02 01 00 02 01 00分别是error-status和error-index正常请求两个都是0。再往里的30 0B 30 09 06 05 2B 06 01 04 01...就是varbind列表2B是1.3的BER编码写法后面整段就是你要读的OID。响应报文结构几乎一样区别在PDU类型从A0变成了A2即GetResponse-PDU。varbind里的Null会被替换成实际值。如果你在Wireshark里展开解析树看到的四层结构更直观SNMP message - version - community - PDU。Wireshark已经帮你把hex翻译成结构树了但你得知道它翻译的是什么才能保证理解不出错。2.2 MIB对象与OID温湿度数据到底藏在哪里前面请求里那个OID1.3.6.1.4.1.xxxxx...就是温湿度数据在SNMP世界的门牌号。OID结构很讲究1.3.6.1.4.1是enterprises节点后面是企业自定义的厂商编号和私有MIB分支。不同厂商的OID设计不怎么统一有的把温度放在.1.1湿度放在.1.2有的则把两个值打包成一个表格。你想直接从抓包看懂温湿度值关键就是把OID列表和设备说明书里的MIB对象对起来。Wireshark里看SNMP响应OID旁边会显示一串数字比如1.3.6.1.4.1.99999.1.1.0如果你装了对应的MIB文件它还会显示成类似tempHumidityTempValue这样的名称。没装MIB也不影响分析OID后面的value字段会直接给出数值比如温度25湿度60这类值很多时候就是实际读数。MIB文件放哪、怎么生效也有讲究。Wireshark里在Preferences - Protocols - SNMP - MIB directories里添加MIB目录把厂商提供的MIB文件放进去。装完MIB之后重新打开抓包文件协议树里会多出对象名这个层级排障时用对象名搜索比翻数字OID快得多。2.3 SNMP轮询的特点和局限性用SNMP读温湿度最大的特点就是简单、轻量、无状态一个Get请求过去一个Response回来UDP包丢了就丢了。这也决定了它适合定时轮询设备健康状态这类低频场景比如监控平台每隔1-5分钟读一次温度、湿度、设备运行时间。但指望用SNMP做高速采集不行轮询间隔太短、请求并发太高设备侧处理不过来就会丢响应监控平台就会报超时。另外SNMP在设计上对值的表达就是简单的类型加数值它不会像Modbus那样给你一个明确的寄存器地址映射所以做数据归档时平台侧更依赖OID语义的绑定。换句话说SNMP适合看着状态Modbus TCP适合高速取数两者定位天然不同。3. Modbus TCP报文深度拆解502端口上的寄存器读写3.1 MBAP头与PDU一条读寄存器指令是怎么发出去的Modbus TCP的报文结构比SNMP要规整得多因为它要跟传统串口Modbus兼容。一条完整的Modbus TCP报文由MBAP头加PDU组成。MBAP头一共7字节事务处理标识符2字节、协议标识符2字节、长度2字节、单元标识符1字节。接下来才是PDU也就是功能码加上数据。我直接贴一段抓到的读温湿度报文请求方向00 01 00 00 00 06 FF 04 00 00 00 02逐字节拆开00 01是事务ID这次通信的序号响应里必须是同一个值。00 00是协议IDModbus TCP固定为0。00 06是长度它表示后面还有6个字节也就是从单元标识符开始算起的剩余长度。FF是单元标识符相当于串口Modbus里的从站地址。因为TCP本身已经通过IP定位设备了这个值默认用FF或01都常见。04是功能码表示读输入寄存器。00 00是起始寄存器地址十六进制表示从0号寄存器开始读。00 02是读取数量表示连续读2个寄存器对应温度和湿度各占一个。响应方向会有些变化典型这样00 01 00 00 00 07 FF 04 04 0F A0 02 58事务ID00 01和请求对上说明这是同一次事务的应答。长度00 07表示后跟7字节。功能码04前面是请求的04无异常时响应功能码不变。数据区第一个04表示后面有4字节数据。0F A0和02 58就是读到的两个寄存器值。Wireshark里展开Modbus TCP节点会把事务ID、长度、单元ID、功能码、寄存器地址这些字段分别列出来。默认解析器还能识别常见功能码并翻译成Read Input Registers这种可读文本比对着hex看省力得多。3.2 功能码04与03输入寄存器、保持寄存器的选择温湿度变送器支持Modbus时寄存器配置每家不同。功能码03是读保持寄存器功能码04是读输入寄存器。别看都是读在设备内部对应的是两片不同的存储区保持寄存器通常可读可写一般用来放配置参数输入寄存器通常只读一般用来放实时采集值。按我的经验变送器厂商往往更愿意用04读输入寄存器因为温度和湿度天然就是只读的实时数据。但有些老设备兼容PLC逻辑把所有数据映射到保持寄存器区域用03也能读。实际调试时如果功能码03读取超时可以试试04反之亦然。当然最好先看说明书里的寄存器表上面会直接写明温度 保持寄存器 40001还是输入寄存器 30001。温湿度数据有时候还会出现一个地址映射的坑——说明书里写的是40001你命令里写成地址0怎么读不到这里要展开说一句。Modbus协议层的地址编码确实是从0开始的但很多组态软件和屏厂习惯用PLC风格的地址编号显示为40001表示1号保持寄存器。所以你在软件里看到的40001对应到协议报文里的起始地址是0x000040002对应0x0001依此类推。别张嘴就问地址到底从0开始还是从1开始要问清楚你说的是协议层地址还是屏端显示地址。3.3 温湿度数据解析字节序、精度与负温度寄存器读回来了真正要命的是怎么把裸数字翻译成温度值。上一节响应里的0F A0和02 58是两个原始整形数按Modbus惯例是大端字节序。如果设备定义的温度精度是0.1摄氏度温度原始值0x0FA0 十进制40004000 / 10 25.6摄氏度。湿度原始值0x0258 十进制600600 / 10 60.0%RH。这里有两个陷阱必须注意。第一个是负温度。冬天配电房如果零下温度原始值会以补码出现。比如传感器读数是 -10.0摄氏度原始值就是 -100十六进制表示是FF 9C。你在Wireshark里直接看unsigned decimal它会显示65436而不是-100会误判成100多度。所以在自己的算法里必须把寄存器当有符号int16处理不能按无符号数。第二个是精度因子。有的设备精度是0.1有的是0.01还有的是直接把整数当温度不加缩放。你要是拿0.01倍的设备当0.1倍去解析25.55摄氏度就会显示成255.5度。这类问题抓包是能看出来的先用上位机已知的正确值做一次对照再回头看原始hex就能确定缩放因子。还有些高端变送器会用32位浮点数表示温湿度一个数值占两个寄存器。这时候你就得按IEEE754格式解析4字节里第1字节是指数位和符号位后3字节是尾数。Wireshark里如果勾选了按Float解析显示会直接给出小数。但你自己写采集程序时别指望所有设备都按标准来大小端次序就够折腾一阵。3.4 实测现场的TCP行为与异常判断Modbus TCP本身跑在TCP上所以你要把传输层的现象也纳入分析视野。比如你用Wireshark抓包经常看到一个TCP连接是长连接的监控软件发起TCP握手然后在这个连接上持续发Modbus请求设备持续回响应。这种情况下如果中间设备重启、网络抖动TCP连接断掉重连后事务ID会从头计数别把它当成异常。出现TCP重传、Dup ACK时也不要上来就甩锅给设备。抓包分析要分层看如果设备根本没回TCP层的ACK那是网络链路问题如果ACK正常、Modbus响应却迟到那是应用层处理慢。Wireshark的Time列可以看响应间隔正常情况下毫秒级完成如果间隔到了几百毫秒甚至秒级多半是设备侧逻辑处理不过来了。4. 抓包分析的标准流程和实操技巧4.1 从捕获文件到定位问题的完整路径我的方法基本是四步走一次抓包抓全、按协议分层统计、逐个事务核对、异常事务用追踪流深挖。第一步抓包时不要轻易关闭捕获让设备端的监控平台或采集软件跑一个完整轮询周期这样你既有正常报文也有异常报文形成对照组。第二步打开Wireshark的Statistics - Protocol Hierarchy你能立刻看到整个抓包文件里TCP、UDP、ARP等协议的分布比例马上判断出有没有大量广播包或者重传包污染数据。第三步按前面说到的过滤器把Modbus和SNMP报文分别筛出来重点核对事务ID、功能码、异常码。第四步遇到某条异常报文右键选择Follow - TCP Stream把整个连接里的双向数据放在一个窗口里看时序关系一目了然。这套流程不一定需要高深技巧最大的价值是让你形成固定套路不至于每次都是打开抓包文件然后发呆。4.2 场景化显示过滤器组合方案显示过滤器用得对分析效率翻倍。我在处理温湿度变送器这类设备时常用的组合有这些排查目标过滤器写法说明只看该设备所有流量ip.addr 192.168.1.100最基础先收窄范围只看Modbus异常响应modbus modbus.func_code 0x80功能码最高位变1表示异常只看某台设备的SNMP get 请求snmp.command 0 and ip.src 192.168.1.1000即GetRequest只看读取特定寄存器数量modbus.read_holding_regs modbus.reg_qty 2核对读取范围只看TCP重传tcp.analysis.flags快速找传输层异常有点暴力但好用注意第二行有个细节。Modbus异常响应的功能码是请求功能码加0x80比如请求读输入寄存器04异常响应功能码就成了0x84。Wireshark的字段名不一定叫func_code你在协议树里看到哪个字段直接用右键复制就是最保险的。4.3 时间显示、数据可视化与效率提升抓包文件里时间如果显示成UTC或者从起始秒数你得主动调整。View - Time Display Format - Date and Time of Day再配合你的本地时区就能看到每次通信的具体时刻排查为什么每天凌晨3点网络中断这类问题时会很直观。Wireshark还能做I/O Graph在Statistics - I/O Graph里按过滤器统计一段时间内的报文速率判断采集软件是不是周期性突发发包。现场如果遇到监控平台偶尔延迟、偶尔超时结合图形看突发峰值往往能发现采集线程把轮询请求积压后一次性发出去这类隐藏问题。5. 常见问题排查与避坑记录5.1 Modbus与SNMP典型故障速查表这一节都是实战里反复遇到的我直接整理成速查表现象可能原因检查点和处理方式Modbus读请求发出但无响应IP不通、端口未开放、Unit ID不对先Ping设备IP确认服务端口是502用默认FF或1试响应功能码0x84且带Exception Code 02寄存器地址非法核对设备寄存器表确认起始地址和数据长度没有越界响应功能码0x84且Exception Code 03写入值非法确认写入的数据类型、取值范围与寄存器属性相符SNMP Get请求无响应UDP丢包、团体名不对、设备IP限制看有没有ICMP端口不可达换public团体核对访问控制列表SNMP响应OID返回noSuchObjectOID不存在用MIB Browser扫设备支持的OID树别照抄其他型号温度显示成负100度精度因子/字节序/符号位处理错误把原始hex和实际显示对照更可能有符号/无符号问题监控平台偶发超时轮询间隔太短、并发过高、设备CPU满拉长轮询间隔串行化请求看设备日志的CPU占用率5.2 调试工具的合规选择有人问我Modbus Poll、Modbus Slave这类调试软件的密钥问题我统一回复一句别为这事费劲更没必要想办法绕过授权。Modbus Poll官方有试用版基本调试功能够用开源界有QModMaster完全免费能模拟主站读写实在不行你手里还有Wireshark再配合一个最朴素的手工计算器一样能把报文算明白。调试的目的是看懂协议数据而不是跟授权较劲正版试用和开源方案在绝大多数调试场景里反而更省时间。5.3 两台设备、两个真实案例的排查记录分享两个我印象深刻的案例。第一个案例发生在一次机房动环改造现场。温湿度变送器能通过SNMP被监控平台正常读到温度但配套SCADA组态软件用Modbus TCP读同一台设备一直超时。我抓包后第一眼就发现组态软件发出的TCP握手包是正常的设备端也有ACK回包但端口不是502而是5020。原因是这台设备的Modbus TCP服务默认跑在5020上需要在设备网页管理页面里手动改端口。这种问题不看报文永远猜不透。第二个案例更有代表性。一套仓储温湿度监测系统部署后某区域变送器读数突然变成 -273.1摄氏度这个数字一看就有问题。抓包后查看原始hex温度寄存器值是0xFFCEUI层按有符号解析是 -50摄氏度但采集服务端在中间环节把它当无符号short存成了负数包了一层转换最终显示结果就崩了。整个链路里只有Wireshark抓到的原始包是可信的上层任何中间件都可能是bug来源。这两个案例说明什么设备报的文字信息会骗人上层软件的显示会骗人唯一不骗人的是线缆上的原始报文。这也是我一直推荐工程师遇到环境监测类联调问题第一反应先抓包的原因。6. 抓包之后还能做什么抓到包并读懂了报文事情才完成一半。SNMP和Modbus TCP都是国际公开标准你完全可以按照抓到的报文格式用Python或者Go写一个温湿度采集服务Modbus TCP用pymodbus库可以几分钟上手SNMP用pysnmp库也能快速实现Get请求。抓包分析最大的价值就是给你提供了一个协议行为基准之后的开发、测试、排障都能对着这个基准来。接着往下扩展还有不少值得玩的方向把Wireshark抓包文件和MIB库放到版本管理里作为每个项目的交付物之一给每台设备的寄存器表做一份字段映射表维护好精度、类型、端点在采集系统里加上原始报文的十六进制日志出了问题直接回溯。坚持做这些比迷信任何一款调试软件都更可靠。我个人这些年最大的体会是调试工业传感器不一定非得把协议栈背得滚瓜烂熟但一定要在抓包这件事上形成肌肉记忆。你抓到包、打开解析树、把源IP源端口、目的端口、功能码、寄存器值、时间隔这几个关键信息扫一遍很多疑难杂症当场就能定性。剩下那些说不清道不明的带着抓包文件去问厂商技术支持对方也没法跟你打太极。
Wireshark实战：温湿度变送器SNMP与Modbus TCP抓包报文全解析
调试工业以太网设备最怕的就是现象能看见、原因抓不着。一台以太网温湿度变送器明明说明书上写着支持SNMP和Modbus TCP/IP可你从监控平台上读不到温湿度或者组态软件里寄存器一直超时。这时候把Wireshark打开、抓一遍报文问题往往一眼就能定位。这篇文章我就拿温湿度变送器这个典型场景把SNMP和Modbus TCP/IP两条协议栈在网线上的每一个字节都拆开讲从抓包环境搭起到报文结构、数据解析、故障排查全程按实际调试节奏走一遍。想真正搞懂工业协议、或者正在跟动环监控、机房环境、仓储温湿度采集项目打交道的工程师这篇文章可以直接当操作手册用。1. 抓包环境搭建一台电脑加一块网卡就够了1.1 温湿度变送器为什么要同时支持SNMP和Modbus TCP先说清楚这个场景的底层逻辑。温湿度变送器这类设备在项目里要给两拨系统供数据一拨是网络运维侧的监控平台另一拨是自动化控制侧的SCADA或组态系统。SNMP走的是UDP 161端口本质是网络管理协议用来做设备状态纳管和资产监控Modbus TCP/IP走的是TCP 502端口本质是工业数据采集协议用来周期性读取寄存器里的实时数值。一台设备同时支持两种协议栈不是厂商在堆功能而是因为它要同时服务于这两个完全不同的数据消费方。SNMP把设备当成一个网络管理对象读它的时候用的是GET请求、OID标识、MIB库这套语言Modbus TCP把设备当成一个数据寄存器表读取时用功能码加寄存器地址这套语言。你如果只会其中一种遇到对面系统联调时就容易抓瞎。我打个你容易记的比方SNMP像是给物业中心上报我这里有人住着、室温多少、门禁是否正常是管理方主动来查Modbus TCP更像是直接把水电表的数据表打开你随时过来抄数字。两类协议的报文长得完全不一样必须分开拆。1.2 抓包前的软硬件准备与抓包位置选择硬件上其实非常朴素一台带网口的PC、一根网线再把变送器供电接好。连接方式有两种一是变送器和PC直连用静态IP配上同一网段二是中间串一个小交换机用Wireshark在PC上抓全部流量。直连适合单设备调试串交换机适合现场有多台设备、要顺便看广播和冲突的情况。软件层面就去官网装最新版Wireshark。安装时有个细节要注意Windows下安装Wireshark会顺带装Npcap这个驱动是抓包的基础宁可多花两分钟把Install Npcap勾上也不要用旧版WinPcap不然在Win10/11上经常抓不到包。装完之后打开Wireshark如果能看到你网卡名字且在线基本就绪。抓包前还有一步容易忽略把PC上无关的流量压下来。Windows更新、远程桌面、杀毒软件后台扫描都会让抓包文件里堆满垃圾包。调试期间建议把设备IP固定好在同一网段比如变送器配置为192.168.1.100PC配置为192.168.1.50然后在Wireshark的捕获过滤器里提前写一条规则这一步能帮你省掉很多后续筛选时间。1.3 Wireshark过滤器语法先定一个调子Wireshark有两层过滤捕获过滤和显示过滤。捕获过滤是在抓包前就决定哪些包进内存显示过滤是抓完之后再从文件里筛选。平时我推荐宽进严出捕获过滤只限制IP和端口显示过滤再按业务场景精确筛选。推荐几组起步过滤器目的捕获过滤语法显示过滤语法只抓温湿度变送器host 192.168.1.100ip.addr 192.168.1.100只抓SNMPudp port 161udp.port 161只抓Modbus TCPtcp port 502tcp.port 502两者都要host 192.168.1.100 and (udp port 161 or tcp port 502)(ip.addr 192.168.1.100) and (udp.port 161 or tcp.port 502)显示过滤器还有一个实用技巧当你看到报文列表里某个协议被你认出来了右键该字段选择作为过滤器应用或者复制过滤器Wireshark会自动生成正确的过滤表达式。很多新人纠结为什么自己写的过滤器老报红其实就是字段名写错用这个右键复制功能可以避开所有记错字段名的问题。2. SNMP报文深度拆解UDP 161端口上的读操作全程2.1 一次完整SNMP请求与响应报文逐字节分析SNMP抓包最典型的就是一条Get请求配一条GetResponse响应。我们先看请求方向。我挑一段抓到的典型SNMPv2c报文把hex转储拆开讲。先看头部30 26 02 01 01 04 06 70 75 62 6C 69 63 A0 19 02 04 55 4A 9E 2E 02 01 00 02 01 00 30 0B 30 09 06 05 2B 06 01 04 01 ...这段怎么读30表示这是一个SEQUENCE后面26是整段长度46字节。02 01 01表示整数类型、长度1字节值为01。这里就是SNMP版本号1代表SNMPv2c如果是0就是v1版。04 06 70 75 62 6C 69 63表示字符串类型、长度6内容是public。这就是请求里带的团体名。很多设备默认读团体就是public抓包时能看到明文。A0 19 02 04 55 4A 9E 2E才是PDU核心。A0代表GetRequest-PDU后面跟着request-id也就是请求序号0x554A9E2E。02 01 00 02 01 00分别是error-status和error-index正常请求两个都是0。再往里的30 0B 30 09 06 05 2B 06 01 04 01...就是varbind列表2B是1.3的BER编码写法后面整段就是你要读的OID。响应报文结构几乎一样区别在PDU类型从A0变成了A2即GetResponse-PDU。varbind里的Null会被替换成实际值。如果你在Wireshark里展开解析树看到的四层结构更直观SNMP message - version - community - PDU。Wireshark已经帮你把hex翻译成结构树了但你得知道它翻译的是什么才能保证理解不出错。2.2 MIB对象与OID温湿度数据到底藏在哪里前面请求里那个OID1.3.6.1.4.1.xxxxx...就是温湿度数据在SNMP世界的门牌号。OID结构很讲究1.3.6.1.4.1是enterprises节点后面是企业自定义的厂商编号和私有MIB分支。不同厂商的OID设计不怎么统一有的把温度放在.1.1湿度放在.1.2有的则把两个值打包成一个表格。你想直接从抓包看懂温湿度值关键就是把OID列表和设备说明书里的MIB对象对起来。Wireshark里看SNMP响应OID旁边会显示一串数字比如1.3.6.1.4.1.99999.1.1.0如果你装了对应的MIB文件它还会显示成类似tempHumidityTempValue这样的名称。没装MIB也不影响分析OID后面的value字段会直接给出数值比如温度25湿度60这类值很多时候就是实际读数。MIB文件放哪、怎么生效也有讲究。Wireshark里在Preferences - Protocols - SNMP - MIB directories里添加MIB目录把厂商提供的MIB文件放进去。装完MIB之后重新打开抓包文件协议树里会多出对象名这个层级排障时用对象名搜索比翻数字OID快得多。2.3 SNMP轮询的特点和局限性用SNMP读温湿度最大的特点就是简单、轻量、无状态一个Get请求过去一个Response回来UDP包丢了就丢了。这也决定了它适合定时轮询设备健康状态这类低频场景比如监控平台每隔1-5分钟读一次温度、湿度、设备运行时间。但指望用SNMP做高速采集不行轮询间隔太短、请求并发太高设备侧处理不过来就会丢响应监控平台就会报超时。另外SNMP在设计上对值的表达就是简单的类型加数值它不会像Modbus那样给你一个明确的寄存器地址映射所以做数据归档时平台侧更依赖OID语义的绑定。换句话说SNMP适合看着状态Modbus TCP适合高速取数两者定位天然不同。3. Modbus TCP报文深度拆解502端口上的寄存器读写3.1 MBAP头与PDU一条读寄存器指令是怎么发出去的Modbus TCP的报文结构比SNMP要规整得多因为它要跟传统串口Modbus兼容。一条完整的Modbus TCP报文由MBAP头加PDU组成。MBAP头一共7字节事务处理标识符2字节、协议标识符2字节、长度2字节、单元标识符1字节。接下来才是PDU也就是功能码加上数据。我直接贴一段抓到的读温湿度报文请求方向00 01 00 00 00 06 FF 04 00 00 00 02逐字节拆开00 01是事务ID这次通信的序号响应里必须是同一个值。00 00是协议IDModbus TCP固定为0。00 06是长度它表示后面还有6个字节也就是从单元标识符开始算起的剩余长度。FF是单元标识符相当于串口Modbus里的从站地址。因为TCP本身已经通过IP定位设备了这个值默认用FF或01都常见。04是功能码表示读输入寄存器。00 00是起始寄存器地址十六进制表示从0号寄存器开始读。00 02是读取数量表示连续读2个寄存器对应温度和湿度各占一个。响应方向会有些变化典型这样00 01 00 00 00 07 FF 04 04 0F A0 02 58事务ID00 01和请求对上说明这是同一次事务的应答。长度00 07表示后跟7字节。功能码04前面是请求的04无异常时响应功能码不变。数据区第一个04表示后面有4字节数据。0F A0和02 58就是读到的两个寄存器值。Wireshark里展开Modbus TCP节点会把事务ID、长度、单元ID、功能码、寄存器地址这些字段分别列出来。默认解析器还能识别常见功能码并翻译成Read Input Registers这种可读文本比对着hex看省力得多。3.2 功能码04与03输入寄存器、保持寄存器的选择温湿度变送器支持Modbus时寄存器配置每家不同。功能码03是读保持寄存器功能码04是读输入寄存器。别看都是读在设备内部对应的是两片不同的存储区保持寄存器通常可读可写一般用来放配置参数输入寄存器通常只读一般用来放实时采集值。按我的经验变送器厂商往往更愿意用04读输入寄存器因为温度和湿度天然就是只读的实时数据。但有些老设备兼容PLC逻辑把所有数据映射到保持寄存器区域用03也能读。实际调试时如果功能码03读取超时可以试试04反之亦然。当然最好先看说明书里的寄存器表上面会直接写明温度 保持寄存器 40001还是输入寄存器 30001。温湿度数据有时候还会出现一个地址映射的坑——说明书里写的是40001你命令里写成地址0怎么读不到这里要展开说一句。Modbus协议层的地址编码确实是从0开始的但很多组态软件和屏厂习惯用PLC风格的地址编号显示为40001表示1号保持寄存器。所以你在软件里看到的40001对应到协议报文里的起始地址是0x000040002对应0x0001依此类推。别张嘴就问地址到底从0开始还是从1开始要问清楚你说的是协议层地址还是屏端显示地址。3.3 温湿度数据解析字节序、精度与负温度寄存器读回来了真正要命的是怎么把裸数字翻译成温度值。上一节响应里的0F A0和02 58是两个原始整形数按Modbus惯例是大端字节序。如果设备定义的温度精度是0.1摄氏度温度原始值0x0FA0 十进制40004000 / 10 25.6摄氏度。湿度原始值0x0258 十进制600600 / 10 60.0%RH。这里有两个陷阱必须注意。第一个是负温度。冬天配电房如果零下温度原始值会以补码出现。比如传感器读数是 -10.0摄氏度原始值就是 -100十六进制表示是FF 9C。你在Wireshark里直接看unsigned decimal它会显示65436而不是-100会误判成100多度。所以在自己的算法里必须把寄存器当有符号int16处理不能按无符号数。第二个是精度因子。有的设备精度是0.1有的是0.01还有的是直接把整数当温度不加缩放。你要是拿0.01倍的设备当0.1倍去解析25.55摄氏度就会显示成255.5度。这类问题抓包是能看出来的先用上位机已知的正确值做一次对照再回头看原始hex就能确定缩放因子。还有些高端变送器会用32位浮点数表示温湿度一个数值占两个寄存器。这时候你就得按IEEE754格式解析4字节里第1字节是指数位和符号位后3字节是尾数。Wireshark里如果勾选了按Float解析显示会直接给出小数。但你自己写采集程序时别指望所有设备都按标准来大小端次序就够折腾一阵。3.4 实测现场的TCP行为与异常判断Modbus TCP本身跑在TCP上所以你要把传输层的现象也纳入分析视野。比如你用Wireshark抓包经常看到一个TCP连接是长连接的监控软件发起TCP握手然后在这个连接上持续发Modbus请求设备持续回响应。这种情况下如果中间设备重启、网络抖动TCP连接断掉重连后事务ID会从头计数别把它当成异常。出现TCP重传、Dup ACK时也不要上来就甩锅给设备。抓包分析要分层看如果设备根本没回TCP层的ACK那是网络链路问题如果ACK正常、Modbus响应却迟到那是应用层处理慢。Wireshark的Time列可以看响应间隔正常情况下毫秒级完成如果间隔到了几百毫秒甚至秒级多半是设备侧逻辑处理不过来了。4. 抓包分析的标准流程和实操技巧4.1 从捕获文件到定位问题的完整路径我的方法基本是四步走一次抓包抓全、按协议分层统计、逐个事务核对、异常事务用追踪流深挖。第一步抓包时不要轻易关闭捕获让设备端的监控平台或采集软件跑一个完整轮询周期这样你既有正常报文也有异常报文形成对照组。第二步打开Wireshark的Statistics - Protocol Hierarchy你能立刻看到整个抓包文件里TCP、UDP、ARP等协议的分布比例马上判断出有没有大量广播包或者重传包污染数据。第三步按前面说到的过滤器把Modbus和SNMP报文分别筛出来重点核对事务ID、功能码、异常码。第四步遇到某条异常报文右键选择Follow - TCP Stream把整个连接里的双向数据放在一个窗口里看时序关系一目了然。这套流程不一定需要高深技巧最大的价值是让你形成固定套路不至于每次都是打开抓包文件然后发呆。4.2 场景化显示过滤器组合方案显示过滤器用得对分析效率翻倍。我在处理温湿度变送器这类设备时常用的组合有这些排查目标过滤器写法说明只看该设备所有流量ip.addr 192.168.1.100最基础先收窄范围只看Modbus异常响应modbus modbus.func_code 0x80功能码最高位变1表示异常只看某台设备的SNMP get 请求snmp.command 0 and ip.src 192.168.1.1000即GetRequest只看读取特定寄存器数量modbus.read_holding_regs modbus.reg_qty 2核对读取范围只看TCP重传tcp.analysis.flags快速找传输层异常有点暴力但好用注意第二行有个细节。Modbus异常响应的功能码是请求功能码加0x80比如请求读输入寄存器04异常响应功能码就成了0x84。Wireshark的字段名不一定叫func_code你在协议树里看到哪个字段直接用右键复制就是最保险的。4.3 时间显示、数据可视化与效率提升抓包文件里时间如果显示成UTC或者从起始秒数你得主动调整。View - Time Display Format - Date and Time of Day再配合你的本地时区就能看到每次通信的具体时刻排查为什么每天凌晨3点网络中断这类问题时会很直观。Wireshark还能做I/O Graph在Statistics - I/O Graph里按过滤器统计一段时间内的报文速率判断采集软件是不是周期性突发发包。现场如果遇到监控平台偶尔延迟、偶尔超时结合图形看突发峰值往往能发现采集线程把轮询请求积压后一次性发出去这类隐藏问题。5. 常见问题排查与避坑记录5.1 Modbus与SNMP典型故障速查表这一节都是实战里反复遇到的我直接整理成速查表现象可能原因检查点和处理方式Modbus读请求发出但无响应IP不通、端口未开放、Unit ID不对先Ping设备IP确认服务端口是502用默认FF或1试响应功能码0x84且带Exception Code 02寄存器地址非法核对设备寄存器表确认起始地址和数据长度没有越界响应功能码0x84且Exception Code 03写入值非法确认写入的数据类型、取值范围与寄存器属性相符SNMP Get请求无响应UDP丢包、团体名不对、设备IP限制看有没有ICMP端口不可达换public团体核对访问控制列表SNMP响应OID返回noSuchObjectOID不存在用MIB Browser扫设备支持的OID树别照抄其他型号温度显示成负100度精度因子/字节序/符号位处理错误把原始hex和实际显示对照更可能有符号/无符号问题监控平台偶发超时轮询间隔太短、并发过高、设备CPU满拉长轮询间隔串行化请求看设备日志的CPU占用率5.2 调试工具的合规选择有人问我Modbus Poll、Modbus Slave这类调试软件的密钥问题我统一回复一句别为这事费劲更没必要想办法绕过授权。Modbus Poll官方有试用版基本调试功能够用开源界有QModMaster完全免费能模拟主站读写实在不行你手里还有Wireshark再配合一个最朴素的手工计算器一样能把报文算明白。调试的目的是看懂协议数据而不是跟授权较劲正版试用和开源方案在绝大多数调试场景里反而更省时间。5.3 两台设备、两个真实案例的排查记录分享两个我印象深刻的案例。第一个案例发生在一次机房动环改造现场。温湿度变送器能通过SNMP被监控平台正常读到温度但配套SCADA组态软件用Modbus TCP读同一台设备一直超时。我抓包后第一眼就发现组态软件发出的TCP握手包是正常的设备端也有ACK回包但端口不是502而是5020。原因是这台设备的Modbus TCP服务默认跑在5020上需要在设备网页管理页面里手动改端口。这种问题不看报文永远猜不透。第二个案例更有代表性。一套仓储温湿度监测系统部署后某区域变送器读数突然变成 -273.1摄氏度这个数字一看就有问题。抓包后查看原始hex温度寄存器值是0xFFCEUI层按有符号解析是 -50摄氏度但采集服务端在中间环节把它当无符号short存成了负数包了一层转换最终显示结果就崩了。整个链路里只有Wireshark抓到的原始包是可信的上层任何中间件都可能是bug来源。这两个案例说明什么设备报的文字信息会骗人上层软件的显示会骗人唯一不骗人的是线缆上的原始报文。这也是我一直推荐工程师遇到环境监测类联调问题第一反应先抓包的原因。6. 抓包之后还能做什么抓到包并读懂了报文事情才完成一半。SNMP和Modbus TCP都是国际公开标准你完全可以按照抓到的报文格式用Python或者Go写一个温湿度采集服务Modbus TCP用pymodbus库可以几分钟上手SNMP用pysnmp库也能快速实现Get请求。抓包分析最大的价值就是给你提供了一个协议行为基准之后的开发、测试、排障都能对着这个基准来。接着往下扩展还有不少值得玩的方向把Wireshark抓包文件和MIB库放到版本管理里作为每个项目的交付物之一给每台设备的寄存器表做一份字段映射表维护好精度、类型、端点在采集系统里加上原始报文的十六进制日志出了问题直接回溯。坚持做这些比迷信任何一款调试软件都更可靠。我个人这些年最大的体会是调试工业传感器不一定非得把协议栈背得滚瓜烂熟但一定要在抓包这件事上形成肌肉记忆。你抓到包、打开解析树、把源IP源端口、目的端口、功能码、寄存器值、时间隔这几个关键信息扫一遍很多疑难杂症当场就能定性。剩下那些说不清道不明的带着抓包文件去问厂商技术支持对方也没法跟你打太极。
