工业现场通信排错实录：Wireshark抓包分析欧姆龙FINS协议异常（从DA1/DA2未知值说起）

工业现场通信排错实战：Wireshark解码欧姆龙FINS协议DA1/DA2异常之谜

车间里的PLC突然停止响应，操作屏上的报警信息模糊不清——这是许多工业现场工程师的噩梦。当欧姆龙FINS协议通信出现异常时，传统指示灯和软件日志往往只能告诉你"通信失败"，却无法揭示故障的真正根源。本文将带你深入数据包层面，通过Wireshark捕获的真实案例，破解那些官方手册从未记载的DA1/DA2未知值之谜。

1. 当FINS协议遇上现实世界的混乱

在理想实验室环境中，FINS协议的每个字段都如教科书般规范。但走进真实的工厂车间，你会发现协议分析工具中频繁出现标红警告的"Unknown value"提示——特别是DA1（目标节点编号）和DA2（目标单元地址）这两个关键字段。官方文档明确规定了它们的取值范围：

• DA1标准值域：0x01-0x3E（SYSMAC LINK）或0x01-0x7E（SYSMAC NET），0xFF表示广播
• DA2标准值域：0x00（CPU）、0xFE（网络单元）、0x10-0x1F（总线单元）

然而在以下场景中，这些规则频频被打破：

1. 老旧设备混用：2005年前生产的PLC可能使用非标准地址编码
2. 第三方网关干扰：PROFIBUS转FINS网关常会篡改原始地址
3. 固件版本差异：CP1H系列V1.3固件存在特殊的测试模式地址
4. 网络风暴污染：异常的广播包会携带随机地址值

提示：遇到未知值时，首先记录出现频率。偶发的未知值可能是噪声，而持续出现的特定未知值往往暗示特殊设备或配置。

2. Wireshark捕获与分析实战

2.1 构建诊断环境

准备以下工具链组成排错系统：

# 网络拓扑示意 PLC[192.168.250.1] <---> [eth0]Linux抓包机[eth1] <---> HMI[192.168.250.2] # 必要的软件组件 sudo apt install wireshark tshark git clone https://github.com/omron-fins/fins-dissector

关键配置步骤：

1. 镜像端口设置：在管理型交换机上配置端口镜像，将PLC端口流量复制到抓包机
2. 混杂模式启用：sudo ifconfig eth0 promisc
3. 过滤规则预设：fins || udp.port == 9600 || tcp.port == 9600

2.2 异常报文特征提取

通过Wireshark的着色规则快速定位异常包：

典型异常报文结构示例：

FINS/UDP Header ICF: 0x80 (Gateway: True, ResponseRequired: False) DA1: 0xA5 [Unknown value!] ← 异常点 DA2: 0x33 [Unknown value!] ← 异常点 SID: 0x42 Command Code: 0101 (Memory Area Read)

2.3 深度解码技巧

对于反复出现的未知值，可通过以下方法探究其含义：

1. 上下文关联分析：

   • 检查同会话中SNA/SA1/SA2字段是否也存在异常
   • 对比Command Code与Error Code的关联模式

2. 时间序列追踪：

   # 使用tshark提取时间序列特征 tshark -r capture.pcap -Y "fins.da1 == 0xa5" -T fields -e frame.time -e fins.sa1 -e fins.command_code

3. 设备指纹比对： 建立已知设备的地址特征库，当未知值匹配特定设备模式时给出提示

3. 六大典型故障场景解密

3.1 案例1：第三方HMI的地址映射错误

现象：

• DA1持续出现0xC1值
• 伴随Error Code 0x0003（目标地址不存在）

根因： 某品牌HMI在地址映射配置中将PLC节点号错误设置为193（0xC1）而非实际值1

解决方案：

1. 在HMI配置工具中修正FINS节点号
2. 或添加地址转换规则：

# 伪代码示例：地址转换中间件 def translate_da1(original): return 0x01 if original == 0xC1 else original

3.2 案例2：固件版本兼容性问题

现象：

• NJ501系列PLC在启动时发送DA2=0x55的广播包
• 官方文档无此记录

技术内幕： 这是NJ系列V1.2固件引入的硬件自检信号，持续约300ms后恢复正常通信。可通过以下过滤规则避免误判：

!(fins.da2 == 0x55 && frame.time_relative < 0.3)

3.3 案例3：网络风暴引发的地址污染

特征：

• DA1/DA2呈现随机变化
• 伴随极高的包速率（>1000pps）

应急处理：

1. 立即物理隔离受影响网段
2. 使用STP协议加固网络拓扑
3. 配置防火墙规则限制FINS端口流量：

iptables -A INPUT -p udp --dport 9600 -m limit --limit 100/minute -j ACCEPT

4. 构建系统化排错流程

4.1 诊断决策树

graph TD A[发现DA1/DA2未知值] --> B{出现频率} B -->|单次| C[视为网络噪声] B -->|持续| D{是否伴随错误码} D -->|是| E[按错误码处理] D -->|否| F{值是否固定} F -->|是| G[检查设备特殊模式] F -->|否| H[检测网络异常]

4.2 现场验证工具包

制作便携式测试套件，包含：

1. 预配置的抓包设备：Raspberry Pi + 定制镜像
2. 已知正常报文样本：各型号PLC的基准通信包
3. 快速比对脚本：

import pyshark def check_da_abnormalities(pcap_file): cap = pyshark.FileCapture(pcap_file, display_filter='fins') for pkt in cap: if hasattr(pkt.fins, 'da1_unknown') or hasattr(pkt.fins, 'da2_unknown'): print(f'异常包#{pkt.number}: DA1={pkt.fins.da1}, DA2={pkt.fins.da2}')

4.3 长效预防措施

1. 网络架构优化：

   • 为每个FINS子网配置独立的VLAN
   • 启用端口安全功能防止地址欺骗

2. 设备管理规范：

   - [ ] 新设备入网前验证FINS地址配置 - [ ] 定期备份PLC通信参数 - [ ] 固件升级后捕获基准通信样本

3. 异常值知识库建设： 下表记录了我们收集的特殊DA1/DA2值及其含义：

在工业现场摸爬滚打多年后，我逐渐意识到协议分析不仅是技术活，更是一种侦探工作。那些被标记为"Unknown"的字段值，往往是设备最真实的"方言"。记得有一次，某生产线每隔三小时出现通信中断，最终发现是一个老旧的温度传感器在使用0xAA作为节点地址——这个值在官方手册上根本不存在，却是该设备十年前出厂时的默认设置。