bacnet 报文分析

原创已于 2026-03-03 14:31:56 修改 · 830 阅读

18 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#服务器 #运维

于 2026-03-03 14:31:05 首次发布

从你这张 Wireshark 截图里（过滤条件是 bacnet），可以把交互拆成三段：设备发现（Who‑Is / I‑Am）→ 读设备/点表属性（ReadProperty）→ 建立 COV 订阅并收到通知（SubscribeCOVProperty + COV Notification）。下面按“帧类型(APDU/PDU)”和“交互过程”解释。

1) 截图里出现的帧类型（BACnet APDU / PDU）

BACnet 应用层 PDU 大类就这几种（标准定义的 BACnetPDU 选择之一）：

Unconfirmed-REQ：不需要对端 ACK（例如 who-is、i-am）
Confirmed-REQ：需要对端应答（后面会跟 Simple-ACK/Complex-ACK/Error 等）
Simple-ACK：对“无返回数据”的 confirmed 请求的确认（只确认成功）
Complex-ACK：对“有返回数据”的 confirmed 请求的确认（携带返回值）
Error：对某个 confirmed 请求的错误响应（仍然对应同一个 Invoke ID）

（截图里没看到分段相关的 SegmentACK/Abort/Reject。）

2) 角色判断：谁是客户端，谁是设备

从列表里能看到大量：

192.168.1.17 -> 192.168.1.255 Unconfirmed-REQ who-is ...
192.168.1.100 -> 192.168.1.17 I-Am device_45

所以基本可以判断：

192.168.1.17：扫描/上位机/网关（客户端，发起发现、读取、订阅）
192.168.1.100（device_45）：被集成的 BACnet 设备（服务器端，响应、上报）

3) 交互过程（按时间顺序“讲人话”）

A. 发现阶段：Who‑Is / I‑Am（Unconfirmed）

你截图最上面一段连续的：

Unconfirmed-REQ who-is（广播到 192.168.1.255，还带了实例范围，比如 3215633 3215633、203 203、204 204、201 201、202 202 等）
随后出现 I-Am device_45（从 192.168.1.100 回到 192.168.1.17）

含义：

1.17 在用不同的“device instance 范围”做发现（有些工具会按范围/单点去扫，以减少回应风暴）。
设备 1.100 符合其中某次范围查询，于是回一个 I-Am，声明“我是 device_45”。

B. 建立“认识设备”的基本信息：ReadProperty（Confirmed + ACK）

紧接着能看到成对出现的：

Confirmed-REQ readProperty(...) device_45 system-status
Complex-ACK readProperty(...) device_45 system-status

含义：

1.17 在读 Device 对象的 system-status（设备总体状态，常见是 operational / non-operational 等枚举）。
因为 ReadProperty 会返回值，所以用 Complex-ACK 回。

后面还能看到 1.17 对广播发 Who‑Is、对 1.100 做一系列点属性读取（目标对象多次出现：analog-value,2），典型是在做“点表/点属性探测”，为后续订阅或读数做准备。

C. 订阅阶段：SubscribeCOVProperty + ACK + 后续通知

截图中段很关键的一串（目标多为 analog-value,2）：

Confirmed-REQ subscribeCOVProperty(...)
Simple-ACK subscribeCOVProperty(...)（表示订阅请求成功受理）
之后出现：
- Unconfirmed-REQ unconfirmedCOVNotification(...) device_45 analog-value,2 present...

含义：

1.17 对 1.100 发起 COV 属性订阅（不是订阅整个对象，而是订阅某个 property 的变化）。
设备返回 Simple-ACK：订阅建立成功（这里不携带数据，所以是 Simple-ACK）。
当 analog-value,2 的 present-value（或你订阅的属性）发生变化时，设备用 UnconfirmedCOVNotification 主动推送给 1.17（截图里确实出现了 unconfirmed COV 通知）。

D. 为什么有些读会出现 Error / Complex-ACK / Simple-ACK 混在一起？

你截图后半段能看到：

对 readProperty(...) analog-value,2 status-flags / priority-array / event-state ... 有 Complex-ACK（读成功，有返回值）
也有 Error（读失败，可能原因通常是：该属性不支持/访问权限不够/对象实例不存在/数组索引不对等）
还有 Complex-ACK readPropertyMultiple(...)（一次读多个属性/多个对象）

这说明 1.17 很可能在做“自动探测”：把常见属性都读一遍（如 status-flags、priority-array、event-state 等），能读就记录，不能读就返回 Error。

从截图来看，你的直觉基本是对的：这段会话里 192.168.1.17（客户端/上位机）确实在反复围绕 analog-value,2（AV2） 做“探测 + 订阅 + 轮询/补充读取”，所以你会感觉“怎么一直在处理 AV2”。

1) 为什么会一直是 AV2？

在 BACnet 里，一个对象（这里是 analog-value,2）通常对应一个你真正关心的点位。很多上位机/网关的典型流程是：

发现设备：Who-Is / I-Am（你图里有 I-Am device_45）
读取设备状态：如 device_45 system-status
对目标点做能力探测（这一步最容易“刷屏”）
依次读：
- present-value（当前值）
- status-flags（告警/故障/超限等标志）
- priority-array（是否被写入/命令优先级状态）
- event-state / limit 属性（是否有事件/报警逻辑）
- 以及一些上下限（你图里能看到类似 high-limit/low-limit）
建立 COV 订阅：subscribeCOVProperty(...) analog-value,2 ...
收到 COV 通知：unconfirmedCOVNotification(...) ... present...
很多实现还会“COV + 定时校验读”：即使订阅了，也会每隔一段时间再 ReadProperty 一次，防止漏包/设备不按预期上报

所以如果系统只配置了一个点（或只对 AV2 做了订阅/监控），抓包里自然就几乎都是 AV2。

2) 结合你截图里能看到的几个“证据点”

多条 Confirmed-REQ readProperty(… ) analog-value,2 … 后面跟着 Complex-ACK 或 Error
→ 典型“属性探测/点表初始化”行为：能读就 ACK，不能读就 Error。
出现过 subscribeCOVProperty(...) analog-value,2 并且有 Simple-ACK
→ 订阅建立成功。
后续出现 unconfirmedCOVNotification(...) device_45 analog-value,2 presen...
→ 设备在推送 AV2 的变化；上位机会因此继续补充读取其它相关属性（例如 flags/priority 等），看起来就更“围绕 AV2 转”。

3) 需要你确认的两个关键问题（决定“正常”还是“异常”）

A. 你们系统里是不是只配置/只绑定了这一个点（AV2）？

如果是：抓包一直 AV2 完全正常。
如果不是：那可能是点表没下发成功、只订阅成功了一个点、或其它点被过滤/权限失败。

B. 这些 AV2 报文是“不断读”（ReadProperty）还是“不断推送”（COV Notification）？

如果主要是 ReadProperty 高频出现：更像上位机在轮询（可能轮询周期配得太短，或 COV 没按预期工作于是退回轮询）。
如果主要是 UnconfirmedCOVNotification 高频出现：更像 AV2 的值在频繁变化，或设备的 COV 增量/死区（cov-increment）太小导致一直触发。