干电力自动化、SCADA系统调试这一行几乎都会遇到这样的场景站端设备与调度主站之间的通信突然中断或者遥测数据出现跳变厂家说没问题主站说收到的是错的两边来回拉扯最后才发现问题出在链路和报文上。这种时候抓包是最直接的“鉴定器”。我这些年做变电站综合自动化、配电自动化项目的调试和运维Wireshark配合IEC 60870-5-104以下简称IEC 104流量分析是工具箱里使用频率最高的组合之一。下面就把我平时抓包分析IEC 104流量的完整思路和操作步骤整理出来从环境准备、抓包配置到报文结构解读、常见坑排查尽量让刚接触这个协议的新手也能照着操作一遍少走弯路。1. 抓包前必须搞懂的IEC 104报文结构与链路机制1.1 协议分层与报文结构速览IEC 104是IEC 60870-5系列中基于TCP/IP的远动通信协议主要用在电力调度自动化、变电站监控、配电网自动化等场景。它的前身是走串口的IEC 60870-5-101104相当于把101的应用层数据搬到以太网上解决了串口通信距离短、速率低、难以组网的问题。所以你在分析IEC 104报文时ASDU的数据结构很多和101是一致的掌握104之后学101会非常快。一条完整的IEC 104报文由APCI和ASDU两部分组成。APCI固定6字节依次是起始字符0x68、APDU长度一个字节表示后面ASDU加控制域的字节数以及4字节控制域。ASDU才是真正携带业务数据的部分包括类型标识、可变结构限定词、传送原因、公共地址、信息体地址和信息体数据。需要特别记住的是并非所有IEC 104报文都带ASDU。控制域能分成三种帧格式I帧信息帧、S帧监视帧、U帧控制帧。I帧带数据也带序号S帧只有确认序号U帧负责链路控制。所以你在Wireshark里看到很多6字节左右的短报文别以为异常它们大概率是心跳帧或者确认帧。1.2 如何快速区分I帧、S帧、U帧控制域四字节按首字节的低两位区分帧类型。I帧的首字节bit00它包含发送序号N(S)和接收序号N(R)其中N(S)占用控制域前两个字节的低15位N(R)占用后两个字节的低15位。S帧首字节bit01、bit10只带N(R)用于纯确认。U帧首字节bit01、bit11后面跟TESTFR、STARTDT、STOPDT三个命令位和确认位没有序号。这里建议新手先别死记控制域的位布局直接用Wireshark看就好。在报文详情里展开iec104协议树Wireshark会直接帮你标出这是I帧、S帧还是U帧以及N(S)、N(R)、命令类型。重要的是理解三种帧的业务含义I帧是真正传数据的S帧是接收方表示“我收到了”U帧用来建立、停止数据传输以及测试链路。用生活场景类比I帧像发快递S帧像签收回执U帧像打电话说“我要开始发货了”“我不发货了”“你还在吗”。1.3 Wireshark环境准备与端口偏好设置Wireshark内置了IEC 60870-5-104的解码器但能不能自动识别取决于TCP端口和协议的关联是不是配置好。IEC 104的标准端口是TCP 2404这也是绝大多数厂家的默认端口但在改造项目里改端口的情况并不少见。抓包前建议先做一件事打开Wireshark的Edit → Preferences → Protocols → IEC 60870-5-104确认当前端口列表里有2404并把你项目的非标端口也加上。加完之后需要重新开始捕获或重新加载报文才会按新端口解析。有个简单的验证方法抓包后随便点一条TCP数据报文看左下角的协议详情里有没有出现“IEC 60870-5-104”这个协议层。如果没有说明解码没生效要么端口没配对要么需要用右键菜单里的Decode As功能强制指定为IEC 60870-5-104。另外Wireshark的版本不要太老。老版本对带时标的SOE报文、部分扩展ASDU类型支持不够解析会出现字段错位或者“未定义”的情况。用更新频率正常的稳定版就足够。2. 捕获IEC 104流量的实操配置与接口选择2.1 确定抓包位置和网卡接口现场抓包位置决定你能抓到的内容。问题出在主站侧就在主站服务器或前置机的接入端口抓问题在变电站侧就从站端通信管理机或远动装置的接入端口抓链路中间丢报文可能需要交换机镜像口抓。在笔记本上第一个坑就是选错网卡。调试笔记本经常有多个网卡管理网口、业务网口、Wi-Fi、虚拟机虚拟网卡等。选哪块卡用ipconfig确认本机IP是哪块网卡配的就行。如果实在不知道可以打开Wireshark主界面的接口列表看哪块网卡的实时曲线和现场业务流量波动吻合。我个人的习惯是先把业务网卡的IP确认好然后在接口列表里双击对应网卡开始抓而不是用“捕获所有接口”。只选一块网卡文件小干扰少分析时更省心。2.2 捕获过滤器写法与典型场景捕获过滤器在底层就把不想要的流量丢掉重点是“抓得准”。默认通信端口是2404时最常用的捕获过滤器很简单tcp port 2404如果想抓指定主站和从站之间的流量可以写得精确一点host 192.168.1.10 and host 192.168.1.20 and tcp port 2404有些设备通信是基于UDP封装的IEC 104变种虽然不属于标准104但现场偶尔会遇到这时可以按IP抓host 192.168.1.10对做双网冗余的项目主备通道属于不同IP段捕获过滤器可能要同时涵盖多个端口tcp port 2404 or tcp port 2405需要提醒的是捕获过滤器语法和显示过滤器语法不一样前者是底层BPF语法用的是tcp port后者是Wireshark显示过滤语法用的是tcp.port 。两个不要搞混我见过很多人把tcp.port 2404直接写进捕获过滤器结果一条包都抓不到。2.3 显示过滤器配合实时观察抓包开始后实时观察用显示过滤器更舒服。最简单的是iec104这个过滤器会列出所有被解析成IEC 104的报文。看到一层层TCP握手后面跟着STARTDT act、STARTDT con基本链路就通了。如果再细分一点只挑U帧看iec104.apci.type 3只看I帧iec104.apci.type 1只看S帧iec104.apci.type 2不同版本的字段命名可能有差异最稳妥的方法是展开报文详情里的iec104协议树右键点击对应字段选择“应用为过滤器”里的“选中的”选项Wireshark会自动生成正确的过滤表达式。显示过滤器和捕获过滤器结合使用的习惯我一般是捕获时先用tcp port限定范围保证长时间抓包文件不会太大显示过滤器随时调整用来定位特定类型报文。两步配合既省磁盘又方便排查。3. 抓包分析实操从握手到业务报文全流程解读3.1 TCP握手之后还有一个应用层握手在Wireshark里查IEC 104流量不要只看TCP三次握手。TCP三次握手只是建了传输通道IEC 104还有一层应用层握手。主站侧先发一个U帧内容是STARTDT act激活传输从站回一个STARTDT con确认激活之后双方才开始互发I帧数据。这个细节很重要。很多新手在抓包里看到TCP三次握手建立后接着是几个6字节短报文不知道它们是什么。如果展开iec104协议树你会看到U帧的command字段明确写着STARTDT act和STARTDT con。如果TCP通道建立后始终没有STARTDT act说明主站配置或应用逻辑有问题压根没有进入传输阶段。如果STARTDT act发出去了但没收到con可能从站通信模块没启动或连接被中间设备拦截。这个阶段卡住通常是配置层面的问题不是带宽能解决的。3.2 心跳检测TESTFR报文怎么看IEC 104链路建立后为了判断链路是否还活着双方会周期性的发TESTFR act和TESTFR con也就是U帧里的链路测试命令。这个周期一般在10秒到30秒之间具体看设备参数。在抓包里看心跳是否正常比在主站界面上看“通道状态”更直观。只需要筛选U帧按时间排列看TESTFR act和con是不是规律交替出现。如果间隔突然拉长或者act发出去后收不到con说明这条链路虽然TCP没断开但应用层已经失去响应这是排查“通道显示正常但数据不刷新”问题的重要线索。需要注意有些设备在数据传输密集时可能降低心跳频率或者跳过某些心跳周期这不一定代表异常。判断标准是较长的时间窗口内是否仍有规律的心跳交互。3.3 总召唤与响应一条完整的I帧对话主站一般在上电或链路重建后发起总召唤要求从站把所有遥测、遥信状态重新上报一遍。在抓包里这条命令对应ASDU类型100C_IC_NA_1传送原因是6激活确认后续从站回传的数据报文传送原因是20响应总召唤。举个例子打开一条总召唤命令报文在Wireshark详情里能看到类型标识显示为C_IC_NA_1信息体地址往往指向0号地址表示对公共地址下的数据点全部召唤。紧接着的从站回复往往是一长串I帧类型标识各不相同有遥信类型1或3、遥测类型11或13传送原因大多是20。我在写报告或者核对数据时会先用显示过滤器iec104.asdu.typeid 100 or iec104.asdu.cot 20 or iec104.asdu.cot 6把总召唤和响应报文全部筛出来然后再按类型逐条核对。这个思路在联调和验收阶段特别好用能很快看出哪些数据点没有在总召唤里上报。如果传送原因不是20而是其他值比如是9询问请求之类的就要注意从站的响应逻辑是不是和主站预期不一致。3.4 遥测、遥信、遥控报文的字段解读先拿最常见的遥测报文举例。假设从站回传的是带品质描述的归一化遥测类型11。ASDU的布局是类型标识11、可变结构限定词、传送原因、公共地址、信息体地址、归一化值2字节短整数、品质描述1字节。Wireshark会把归一化值直接算成十进制同时显示品质描述里的溢出、越限、无效等标志。如果你看到数值本身合理但品质描述里有“无效”标志说明该点在从站侧已经加了无效状态主站要不要采用取决于主站逻辑。再看遥信。单点遥信类型1的信息体数据只有1个字节0表示分1表示合。双点遥信类型3用1个字节里的两位表示四态00和11是确定的双位置状态01和10属于“不确定”状态常见于断路器辅助接点切换过程中的瞬时态。了解这个能理解为什么变位瞬间会出现短暂的非0非1但随后又稳定的报文。遥控报文方向相反是主站到从站。常见的单点遥控类型45和双点遥控类型46命令信息体数据和遥信类似但还带有一个选择/执行的限定词S/E用于“先选择后执行”的安全操作流程。抓包里如果看到类型45的报文需要确认限定词是“选择”还是“执行”这对排查“遥控拒动”问题非常有帮助。如果只看到选择命令没看到执行命令通常是主站的遥控流程卡在执行环节。4. 抓包分析常见问题与排查技巧实录4.1 抓不到任何IEC 104报文先查这四件事第一件事端口对不对。第二件事网卡选没选对。第三件事交换机镜像配置。第四件事Wireshark解码偏好。这四件事按顺序排查百分之九十的问题都能解决。先快速验证端口抓包里TCP端口是一目了然的如果不是2404也没关系手动把项目实际端口加到协议偏好里就行。网卡问题注意Wi-Fi和虚拟网卡实际数据如果走有线网口你却在无线网卡上抓当然什么都抓不到。镜像问题在很多工业环网和接入交换机上普通端口默认只能看到发往本机的报文看不到其他设备之间的报文解决办法是做端口镜像或者把抓包设备串接在链路上。解码问题报文确实抓到了但详情里没有iec104层此时用Decode As强制指定即可。有一个容易被忽略的场景IEC 104报文走TCPTCP存在分段和重组问题。如果Wireshark没有启用TCP重组的偏好设置某些ASDU比较长的报文会被拆分显示看起来好像报文没有完整到达实际上只是显示层面没重组。在偏好设置里的TCP协议选项中把“允许子分片重组”和“当协议被调用时重组所有TCP流”打开多数显示异常都能解决。4.2 TCP重传、乱序与IEC 104应用层丢包如何区分抓包里出现TCP Retransmission、Dup ACK、Out-of-Order不等于IEC 104协议坏了。TCP层重传往往说明物理链路存在丢包或延迟抖动但TCP的可靠性机制把这些丢了又捡了回来。要判断应用层是否真的丢了数据得看IEC 104自己的序号N(S)和N(R)。逻辑很简单如果从站的N(S)序列在抓包里是连续的比如依次是1、2、3、4中间没跳号那么应用层数据是完整的。哪怕TCP层有重传最终对端收到的数据也是完整的。如果N(S)出现跳号例如从2直接跳到5那才有可能是应用层丢数据或者从站发送逻辑异常。另外IEC 104的S帧确认号N(R)也能看出问题。如果主站一直发I帧从站却迟迟不回S帧抓包里看不到对应的确认说明从站可能卡在处理逻辑上这时候看到的现象就是主站侧反复重发。这种情况要优先查主站的确认机制和从站的处理进程而不是一上来就怀疑网络。4.3 同一个报文重复出现不是网络风暴现场经常有一个现象从站主动上送了一条遥信变位报文主站侧却抓到了好几条一模一样的。很多新手第一反应是“广播风暴”其实大概率是IEC 104的重传机制在工作。当从站发完一条I帧后如果在一定超时时间内没有收到主站的S帧或I帧确认它就会重发这条报文。所以你看到重复报文本质是从站认为主站没收到。想确认这一点就把抓包时间线拉长在两条相同报文之间找找有没有主站发往从站的S帧。如果一直没有确认帧说明主站的接收处理或者确认帧构造有问题。建议这种问题结合TCP层一起看。有时候从站重发是因为TCP层的ACK已经返回但IEC 104应用层的S帧还没发出这多半是主站协议栈处理慢导致的。这类问题根源在软件处理性能不在网络。把主站侧报文处理日志打开通常能比抓包更早看到瓶颈。4.4 SOE时标异常排查思路带时标的SOE事件报文在抓包里非常显眼类型标识通常是30单点带时标等。点开详情Wireshark会把时标字段直接解析成“2024-XX-XX XX:XX:XX.XXX”格式省了自己换算的功夫。排查时标异常一般分三步先在抓包里筛出所有带时标的ASDU报文并导出然后在表格里把事件时间和主站接收时间做差值看是恒差还是乱差最后根据差值特征定位是RTC问题、对时配置问题还是传输延迟问题。如果差值恒定多半是站端设备RTC走了偏差需要重新对时如果差值无规律大概率是主站对时报文没下发或从站对时逻辑有问题。这里有个容易忽略的边界情况IEC 104时标不携带时区信息。如果站端设备、主站服务器分布在两个时区或者有夏令时切换单看报文时间会出现“看起来差一小时”的假象。遇到这类问题先把时区因素排除再怀疑设备RTC。5. 提升效率的实用技巧过滤、导出与图表5.1 常用显示过滤器组合速查把平时用得最多的过滤器整理成了一张速查表调试时直接套用需求显示过滤器所有IEC 104报文iec104只看U帧控制帧iec104.apci.type 3只看I帧数据帧iec104.apci.type 1只看遥控命令类型45/46iec104.asdu.typeid 45 or iec104.asdu.typeid 46只看遥信变位类型1/3iec104.asdu.typeid 1 or iec104.asdu.typeid 3只看总召唤或响应iec104.asdu.typeid 100 or iec104.asdu.cot 20 or iec104.asdu.cot 6按信息体地址过滤iec104.asdu.ioa 4096如果字段名输进去没有自动补全不要硬记直接在报文详情里右键对应字段选择应用为过滤器Wireshark会自动生成正确的表达式。速查表的价值在于帮你形成条件反射知道有哪些常用的筛选维度不至于面对几千条报文无从下手。5.2 导出CSV批量统计报文如果要做一段时间的遥测数据质量分析或者给客户写验收报告就会用到导出CSV功能。操作步骤先用显示过滤器筛出需要的报文然后File → Export Packet Dissections → As CSV在导出界面勾选需要的列时间、源地址、目标地址、协议、类型标识、信息体地址、数据值等点导出即可。导出的CSV可以用Excel直接打开也可以写一段Python脚本做自动化处理。我常用的一个场景是筛出全部总召唤响应的遥测报文按信息体地址分组把每个点的值列出来和现场监控画面上的值做逐一核对。这样比盯着屏幕逐条看快十倍。导出时有个小细节如果要保留Wireshark解析出来的时间列并需要毫秒精度记得在导出界面勾选对应的显示列否则默认可能只有秒级时间。5.3 IO Graph观察流量节奏联调初期我喜欢在Wireshark的统计功能里看IO Graph快速判断通信节奏是否正常。设置两个过滤器一个是iec104.apci.type 3一个是iec104分别用不同颜色叠加显示。正常情况下你会看到U帧心跳/控制帧以固定周期出现像心电图上的基线I帧流量则在数据变化、总召唤等场景下出现脉冲。如果心跳尖峰消失大概率链路已经出现问题如果整体流量长时间为0则要检查TCP连接是否已经断开。这个图形对向其他人解释问题也很有用截图往测试报告里一放对方很快就明白流量规律。6. 工程现场的经验总结与安全操作建议6.1 用模拟器练习抓包分析如果项目还没开始或者想练习报文解读完全可以在本机搭建一个模拟环境。现在有不少开源的IEC 104从站模拟工具和主站模拟工具Windows和Linux上都有。我经常做的是本机跑一个IEC 104从站模拟器监听2404端口然后用另一个模拟主站工具去连接两者之间用Wireshark抓Loopback接口或者抓一块虚拟网卡上的流量。用模拟器练习的好处是报文完全可控你能随心所欲地触发遥信变位、遥控命令、总召唤等场景再对照Wireshark看报文结构比在现场边抓边猜快得多。尤其是遥控“选择到执行”的完整流程用模拟器走一遍输出报文一目了然。等你在模拟环境里把各种类型报文都过了一遍再到现场抓包就会从容很多因为大部分字段已经眼熟了。6.2 生产环境抓包的几条忌讳抓包本身是只读操作风险很小但工程现场依然有几点要特别注意。第一不要在抓包过程中随意用Wireshark的发送功能、重放功能甚至不要用ping工具对运行中的设备做非业务测试。变电站、配电站里的设备很多有闭锁逻辑非预期报文可能触发保护或误动轻则影响生产重则带来安全事故。第二抓包文件里包含实时运行数据包括开关位置、电度、遥控记录属于敏感信息文件要加密保存不要随意放在共享网盘或者聊天群里。第三如果要重启Wireshark或者切换抓包模式先确认不会影响正在进行的联调和现场负责人口头打个招呼。第四点也是经验之谈抓包时要养成记笔记的习惯。时间、地点、抓包点、过滤器、现场操作动作记在纸上或者便签里后面分析时对照着看很多异常报文其实有对应的现场操作事件不记下来就很容易对不上号。6.3 复盘的记录习惯最后说一个影响长期效率的方法每次抓包结束后把抓包文件命名规范一些比如“项目名_日期_事件_抓包点.pcapng”再配一个简单的说明文本记录筛选条件、问题结论和后续处理。别嫌麻烦这个习惯坚持久了积累下来就是自己专属的“异常报文图鉴”。下次遇到类似问题直接翻记录一眼就能定位方向省下的时间远远超过记录花的那几分钟。用Wireshark分析IEC 104流量技术门槛其实不高难的是把报文和背后的业务逻辑对应起来。每一个STARTDT、每一个N(S)、每一个类型标识背后都对应着现场的一次设备操作、一个告警、一次联动。这几年的项目经验让我最深的一个体会是抓包不是终点而是起点拿到数据以后能快速理解“为什么会出现这个报文”才算真正掌握了这个工具。希望这篇实操分享能帮刚入行的朋友少走几步弯路。如果你在抓包分析中碰到什么奇怪的现象也别急着怀疑协议实现先回到报文本身一层层剥开看答案往往就藏在那些看似多余的字节里。