前几天在客户现场处理一个很典型的故障动环监控大屏上一片飘红三号机柜的温湿度数据停在“通信异常”已经超过两个小时。现场三方各执一词设备厂家说变送器指示灯正常、本地液晶屏还在刷新网络工程师说交换机没有任何告警监控平台那边则一口咬定“就是设备不上报”。三个人的说法放在一起其实是死循环——谁都在说“我这边没问题”可问题又确实存在。后来我拿笔记本接到设备所在的接入交换机上用Wireshark抓了三十秒的包真相就清楚了采集服务器的Modbus TCP请求根本没到达设备连TCP 502端口的SYN都没出现过而设备侧通过SNMP发给网管平台的应答却在正常响应。故事看起来简单但里面其实覆盖了工业以太网温湿度变送器调试中最常用的两条抓包分析主线SNMP和Modbus TCP/IP。这篇文章不打算铺开讲Wireshark的界面功能重点只放在三个问题上为什么一台变送器里要同时跑两个协议栈、这两种报文在抓包里到底长什么样、出故障时报文怎么把真相说出来。适合做动环监控调试、工业物联网、SCADA系统集成以及经常跟以太网传感设备打交道的朋友们参考。1. 为什么一台温湿度变送器里要同时装SNMP和Modbus TCP两条协议栈1.1 两个协议栈的分工完全不同温湿度变送器现在的设计基本都是“一机两用”SNMP和Modbus TCP同时开放但服务对象和业务定位完全不同。SNMP走的是UDP 161/162端口主要服务对象是网络管理平台。设备在MIB树里暴露系统描述、固件版本、运行时间、设备状态这类管理信息有些厂商还会把实时温湿度放到企业私有OID下。它的特点是无连接、一次UDP包完成一次交互、靠OID寻址、用community字符串做访问控制。打个比方SNMP更像是设备的“体检入口”网管系统定期来打个卡确认设备活着、配置有没有变化、固件是不是最新版。Modbus TCP则走TCP 502端口服务对象是PLC、SCADA、动环采集器这类实时数据采集系统。它基于TCP长连接通过功能码读写寄存器寄存器里保存温湿度测量值、报警阈值、设备状态字。特点是开销小、周期快、结构简单采集周期做到200毫秒甚至更快都没问题。它更像设备的“业务数据出口”生产数据都从这条路出去。为什么要同时开两个服务因为监控中心和数据采集系统往往是两套相互独立的系统协议栈不互通。设备厂商为了兼容两种上游就在固件里同时跑两个服务任务一个监听UDP 161一个监听TCP 502。还有另一个现实原因Modbus TCP虽然拿数据方便但标准Modbus里没有规定设备型号、固件版本这类“自我描述”信息放哪个寄存器而SNMP的MIB树正好补上这一块。抓包如果只盯着其中一种协议就等于把现场线索丢掉了一半。1.2 抓包能一次性回答的几类问题把Wireshark接到设备侧之后一口气能确认的事情包括请求到底有没有到达设备门口目标MAC、IP、端口对不对。设备到底有没有响应应答包是否存在事务ID和请求能不能对应上。返回的数据寄存器原值是多少对照设备手册换算成物理量验证对不对。TCP链路质量如何SYN重传、RTT、Dup ACK、零窗口有没有出现。协议实现偏差在哪里OID不存在、功能码不支持、寄存器地址越界这些在报文里都有明确的错误码。常见的故障场景和对应要看的报文位置我整理了一张表现场现象优先检查的报文位置判断思路平台显示设备超时上行是否有Modbus响应帧有响应说明设备正常问题在采集端处理逻辑设备指示灯正常但数据不刷新下行是否有Modbus请求到达设备请求没到设备查网络路径和采集配置读到的温度是-40℃或65535功能码、起始地址、寄存器数量大概率寄存器区或数据解析方式不匹配SNMP能通但Modbus不通对比两条协议栈的TCP/UDP流量先确认设备服务是否同一IP再补抓502口数据偶尔跳变、断断续续TCP重传、RTO、连接断开重连链路质量差或设备处理不过来结合时间列判断2. 动手抓包前的现场装备和参数准备2.1 三种物理接入方式怎么选抓包设备接错了后面分析全白费。现场常用接入方式有三种第一种是笔记本网卡直连设备网口。最直接但有几个前提设备必须已经独立供电或者你的笔记本网口支持PoE供电这种情况极少。很多温湿度变送器是用PoE从交换机取电的你把网线从PoE交换机口拔下来插到笔记本上设备瞬间断电抓到的包当然是空的。接线前必须先确认设备供电方式。另外PC的IP必须和设备IP在同一网段。这里有个小技巧如果不知道设备当前IP可以先在网卡上配置一个169.254.x.x或192.168.1.x的静态地址然后开Wireshark抓全量包看ARP广播设备一旦通信就会暴露自己的IP和MAC。第二种是交换机镜像端口。把设备上联的交换机端口配置成镜像口把抓包笔记本接到镜像口上不影响业务链路。这是最稳妥的接线方式但需要交换机的配置权限。命令每家厂商不同常见的是port mirror或monitor session抓包前确认镜像方向是both既要RX也要TX。第三种是用集线器Hub把PC和设备串在同一个冲突域。Hub会把所有流量广播到所有端口不需要交换机配置但现在的千兆Hub很少见百兆Hub抓高速流量可能会丢包。小数据量调试可以正经排查不推荐。2.2 Wireshark抓包设置与基础配置打开Wireshark第一件事是选对网卡。Windows下会看到一大堆网卡名以太网、WLAN、VMware Virtual Ethernet Adapter、WAN Miniport等。物理网卡优先不要选虚拟网卡。选网卡时注意看“Packets”列有没有在跑的数那些一直跳的通常才是真正有流量的物理口。进入Capture Options后两个关键设置勾选“Use promiscuous mode on all interfaces”——开启混杂模式。看非本机MAC目标流量时才能抓到包比如通过交换机镜像抓设备与采集服务器之间的通信。Capture Filter和Display Filter是两个完全不同的语法千万别混用。Capture Filter是BPF格式在抓包前过滤语法类似port 502 or port 161Display Filter是Wireshark表达式在抓包后过滤语法类似tcp.port 502 || udp.port 161。我见过不少人把icmp写进Capture Filter以为是在显示过滤结果抓了半天一个包都没有。2.3 预置设备信息清单抓包不是打开就抓抓完再看。在动手之前我建议先把一组信息列在纸上或表格里参数项示例说明设备IP192.168.1.100变送器当前地址设备MAC00:01:02:03:04:05用于区分同类设备Modbus TCP端口502有的厂商会改成非标端口单元ID1网关场景下用来区分从站功能码0x03 / 0x04保持寄存器或输入寄存器寄存器起始地址0x0000注意组态软件显示可能从1开始寄存器数量2或4取决于数据格式数据格式uint16 / int16 / float关键决定换算公式SNMP端口161community通常public温湿度OID1.3.6.1.4.1.xxxxx从MIB文件导入这表格里的东西不知道也不用慌可以从设备铭牌、说明书、官网驱动包里的MIB文件、或者是项目组态软件里反查。但不知道这些就抓包后面很难判断报文内容对不对。3. SNMP报文拆解从GetRequest到Response看管理层如何读变送器3.1 SNMP报文的四层封装SNMP抓包看起来比Modbus抽象因为它的内容不是固定字段的“表格式”结构而是TLV嵌套。一次典型的SNMPv2c GetRequest请求在Wireshark里展开是这样的UDP header Source Port: 48623 Destination Port: 161 SNMP version: v2c (1) community: public data: get-request (0) request id: 0x1a2b3c4d error status: noError (0) error index: 0 varbinds: 1 varbind 1: 1.3.6.1.4.1.23456.3.1.1.0 (humidityCurrent) value: NULL对应的ResponseSNMP version: v2c (1) community: public data: get-response (2) request id: 0x1a2b3c4d error status: noError (0) error index: 0 varbinds: 1 varbind 1: 1.3.6.1.4.1.23456.3.1.1.0 value (INTEGER): 25关键点在于SNMP本身是UDP载荷走的是无连接路径不需要三次握手。所以当你看到“请求发出去了但设备没响”问题可能出在UDP的包被丢弃、设备上SNMP服务没起来、community不匹配这几个方向。它没有TCP那套重传机制来兜底排查时要从应用层面去找原因。3.2 OID寻址1.3.6.1.4.1背后的企业私有树OID的语义很多人一看就头大其实拆开并不复杂1.3.6.1.2.1是标准mib-2树系统组、接口组、IP组都在这里。sysDescr是1.3.6.1.2.1.1.1.0sysName是1.3.6.1.2.1.1.5.0。1.3.6.1.4.1是enterprises企业私有子树下面每个厂商有一个由IANA分配的企业号再往后全是厂商自己定义的内容。温度、湿度、报警状态这类业务数据很少有厂商放到标准mib-2里绝大多数都挂在企业私有子树下。实操中我建议抓包前先用snmpwalk把设备整棵MIB树走一遍找到温湿度节点snmpwalk -v2c -c public 192.168.1.100 .1拿到OID后再在Wireshark里针对性抓包。注意设备随附的MIB文件最好导入到Wireshark里这样varbind会直接显示OID的节点头名称不用去背那一串数字。导入路径是Preferences Name Resolution 勾选SNMP OID resolution然后加载MIB文件。3.3 三类常见SNMP异常在抓包里的长相第一类是设备完全不回包。抓包只能看到请求帧每隔几秒被重复发出——SNMP客户端通常有超时重试机制。这种情况优先排查设备上SNMP服务是否启用、community字符串是否匹配、UDP 161端口是否在监听。第二类是回包但带错误状态。error-status字段不是noError常见值有error-status含义排查方向tooBig (1)响应超过UDP载荷限制MIB节点返回的数据量过大noSuchName (2)请求的OID不存在OID写错对照MIB重新确认badValue (3)变量值非法多见于Set操作noCreation (5)对象不可创建设备不支持该写操作第三类是收到badCommunityName这类共同体不匹配的响应。抓包里能同时看到设备和网管站的IP直接把community改成设备配置的一致即可。补充一个容易误判的情况如果抓到的SNMP报文TCP/UDP层一切正常、payload内容却是一堆不可读的二进制乱码不要急着怀疑抓包有问题。SNMPv3是带认证和加密的报文内容本身就不透明。在这种情况下要继续分析只能配置SNMPv3的用户名、算法和密钥Wireshark里的Protocols SNMP菜单可以设置。4. Modbus TCP报文拆解MBAP头、功能码、寄存器逐字节分析4.1 MBAP头7字节不是白给的Modbus TCP和RTU最大的区别就是多了7字节的MBAP头Modbus Application Protocol Header。以一次读取温湿度寄存器的请求为例抓包展开如下Modbus/TCP Transaction Identifier: 0x0001 Protocol Identifier: 0x0000 Length: 6 Unit Identifier: 1 Modbus Function Code: 3 (Read Holding Registers) Starting Address: 0x0000 Quantity of Registers: 0x0002这7字节拆开看事务标识符Transaction ID2字节每次请求自增用于匹配请求和响应。Modbus TCP允许在同一个TCP连接上并发多个请求事务ID就是对它们做一一对应的“编号”。如果抓包看到请求的事务ID没有递增或者响应的事务ID跟请求对不上极有可能是中间有协议网关在转发篡改或客户端库实现有bug。协议标识符Protocol ID2字节固定为0x0000表示Modbus协议。你看到其他值就要警惕是不是抓错了端口。长度Length2字节是指“Unit Identifier PDU”的字节数。上面例子里Unit ID占1字节、功能码占1字节、起始地址占2字节、寄存器数量占2字节总共6字节。它不算MBAP头自身这个容易记错。单元标识符Unit ID1字节相当于RTU模式里的从站地址。直连变送器时通常是1如果经过网关挂多台设备就会用这个字段区分不同从站。这里有基数问题协议里寄存器地址是0x0000起始但很多组态软件界面显示的“40001”是1起始。Wireshark抓包只认协议字段你填软件地址时按组态软件的习惯看抓包时记得减1对齐。4.2 请求与响应的逐字段对照接着看响应帧Modbus/TCP Transaction Identifier: 0x0001 Protocol Identifier: 0x0000 Length: 7 Unit Identifier: 1 Modbus Function Code: 3 (Read Holding Registers) Byte Count: 4 Register 0: 0x1448 Register 1: 0x0C3C响应里的Transaction ID、Unit ID必须和请求一致Length是71字节Unit ID1字节功能码1字节字节计数4字节数据。Byte Count表明后面跟了多少字节的寄存器数据应该是寄存器数量乘以2。在这个例子里请求读了2个寄存器响应返回4字节完全匹配。功能码的选择要特别注意。0x03是读保持寄存器0x04是读输入寄存器。很多变送器的温度、湿度放在输入寄存器区你用0x03去读虽然也能建立连接、也能收到响应但数据可能全是0或固定值。判断依据只有设备手册抓包本身不会告诉你“该读哪个区”它只会忠实地把响应内容呈现在你面前。4.3 寄存器原值如何换算成温度和湿度这是最容易翻车的一步。两种主流数据格式第一种整数定点数。寄存器0x1448十进制是51920x0C3C十进制是3132。假如设备手册写着“温度分辨率0.01℃、湿度分辨率0.01%RH”那么温度就是5192 ÷ 100 51.92℃湿度是3132 ÷ 100 31.32%RH。换算公式就一个除法但分辨率系数必须看手册。第二种IEEE 754单精度浮点数。温湿度各占4字节、跨2个寄存器。这时候字节序特别关键不同厂商实现不同。常见的有大端顺序ABCD寄存器1的高低位 寄存器2的高低位依次拼成4字节字序交换CDAB寄存器2的高低位 寄存器1的高低位用Python解析时可以这样区分import struct data bytes([0x42, 0xC8, 0x00, 0x00]) # 标准大端 val_be struct.unpack(f, data)[0] # 小端 val_le struct.unpack(f, data)[0] # 字序交换后大端CDAB val_word_swap struct.unpack(f, b.join([data[2:], data[:2]]))[0] print(f大端: {val_be:.2f}, 小端: {val_le:.2f}, 字交换: {val_word_swap:.2f})同一个字节序列三种解析出来的数值天差地别。如果你把设备读回来的数据解析成-42.5℃、113.2℃这种明显不合理的值不要先怀疑设备坏了先换一种字节序试试。4.4 异常响应的报文特征Modbus协议里异常响应会在功能码的最高位置1。比如请求功能码0x03失败响应功能码是0x83同时伴随一个异常码字段异常码名称含义与排查方向0x01Illegal Function功能码不被设备支持确认读保持还是输入寄存器0x02Illegal Data Address起始地址寄存器数量超出设备寄存器范围0x03Illegal Data Value请求中的值非法多见于写操作0x04Slave Device Failure设备内部异常可能是固件状态不对0x06Slave Device Busy设备忙稍后重试抓包中看到0x83 0x02基本可以直接判定是寄存器地址或者数量设置得不合理。看到0x83 0x01说明功能码和设备的寄存器区不匹配。这些信息比设备“报不报故障”要精确得多。5. 从抓包结果反推设备与网络三起真实故障复盘5.1 案例一Modbus请求没到设备SNMP却正常——配置漂移平台上报三号变送器超时设备现场指示灯正常。抓包30秒得到两个重要事实采集服务器定期向192.168.1.101的502端口发Modbus请求但设备当前实际IP是192.168.1.110同时192.168.1.50每秒向192.168.1.110的161端口发SNMP请求设备正常回了GetResponse。这说明设备、网络、SNMP服务全部正常唯一不对劲的是采集平台的IP地址表。后来查明是现场有人调整过DHCP地址池设备重开机后拿到的IP变了采集端没同步更新。处置方法是把设备IP固定掉同时把采集端的目标地址改过来。如果不抓包三方可能还要扯半天。5.2 案例二SNMP读到状态正常Modbus数据却是-40℃——功能码和寄存器区选错设备SNMP里能读到温度值网管平台显示设备健康。但SCADA通过Modbus读回的温度一直是-40.0℃。抓包看到请求是FC03读保持寄存器地址0x0000响应帧也正常返回寄存器原值是0xD8F0。对照手册温度数据实际在输入寄存器区应该用FC04读写地址0x0000保持寄存器区0x0000存的是设备状态字0xD8F0转成十进制就是某个状态码跟温度没有任何关系。把采集配置改成FC04、起始地址0x0000后数据立刻正常。这个案例想说明的是SNMP回包正常只能证明设备“活着”Modbus数据不对要回去核对功能码和寄存器地址不要急着怀疑硬件。5.3 案例三报文被设备静默丢弃——轮询周期太快整柜48路温湿度变送器采集周期200ms。前期运行正常半小时后其中几个设备数据开始断断续续TCP连接反复断开重连。抓包发现一个很有意思的细节请求帧的事务ID在正常递增但每隔几个请求设备的响应帧就消失一次。这不是TCP层丢包因为抓包机和设备在同一个二层环境里更像是设备应用层根本没处理这个请求。配合SNMP侧观察设备SNMP响应非常积极说明TCP/IP协议栈本身是通的问题出在Modbus服务任务的处理能力上。这类低端变送器的固件对Modbus业务很可能就是单线程串行处理。轮询周期太短处理队列溢出时来不及处理的请求直接被丢弃。解决办法是把轮询周期放宽到1秒同时把请求合并成批读——比如用FC03一次读温度、湿度、状态字4个寄存器而不是拆成4次单寄存器请求。调整后请求量直接减少75%问题消失抓包里也能看到请求间隔变得均匀。6. 高频踩坑和效率技巧6.1 抓包网卡这关就拦住了一半人用笔记本自带的有线网卡是首选。不要用Wi-Fi来抓工业现场设备的包无线网卡要开监听模式、还要面对802.11管理帧复杂度比有线抓包高一个量级。Windows下有USB转网卡的抓百兆流量可能丢包尤其是镜像口流量本来就大的时候。还有一个被忽略的细节抓本机是采集服务器、设备是对端的时候有些网卡驱动对“发往本机的包”和“本机发出的包”都会采集这没问题但如果采集服务器和抓包机不是同一台机器你就必须开混杂模式并且保证网卡在同一个交换域里。6.2 显示过滤器的语法细节与VLAN处理常见显示过滤器tcp.port 502只看Modbus TCP两条方向udp.port 161只看SNMP两条方向modbus已经被解析为Modbus协议的帧注意与端口过滤的差别snmp显示SNMP协议帧ip.addr 192.168.1.100只看某台设备相关流量ip.addr和ip.src/ip.dst不一样——ip.addr是“源或目标”任一匹配新手容易误以为只是目标匹配。如果想精确过滤某个方向的流量写成ip.dst 192.168.1.100会更严谨。如果交换机镜像口出来的报文带802.1Q VLAN Tag显示过滤器可以用vlan.id 10辅助过滤。不带tag的普通抓包则完全不需要加这个条件。6.3 校准时间线和导出关键报文Wireshark默认显示相对时间从抓包开始经过的秒数。现场排查时我习惯先把它切换成UTC绝对时间View Time Display Format Date and Time of Day。这样才能把抓包和后台日志、操作记录精确对上。比如平台显示“10:31:02 数据超时”你可以在抓包里直接定位到10:31:02前后发生了什么。导出关键报文用File Export Packet Dissections As Plain Text只勾选当前选中的帧这样贴到故障工单里的是干净可读的协议展开文本而不是整个抓包文件。6.4 抓包完毕别忘清理现场最后一件事很多人忽略抓完包后把笔记本从镜像口拔掉、恢复交换机端口配置、把临时设置的静态IP改回去。尤其是通过PoE交换机的端口抓包时你拔插网线动作不对可能会让正在供电的设备掉电重启。抓包记录几个MB的文件建议留着归档后面如果设备出现周期性故障翻旧抓包复盘比重新跑现场省力得多。最后说点个人体会。我做过不少温湿度变送器的调试和验收现在养成一个习惯不管项目里有没有问题第一次接设备都会先抓5分钟的包留底。抓包文件不占多少空间但后面出疑问的时候它比任何截图都有说服力。设备厂家、平台厂商、现场运维三方扯皮时把抓包里“请求到了没、回没回、回得对不对”三个截图贴出来责任边界立刻清楚。这不是工具多高明而是报文不会说谎。以后遇到类似问题不妨也先把Wireshark开起来再说。