BACnet/SC节点WebSocket升级后发送TLS 1.3 Close Notify的原因及保活方法

环境配置 #

通信参数：基于WebSocket的TLS 1.3（wss://…:4443），同一CA签发的ECC P-256证书
标识信息：

• Hub VMAC = 666666666666
• Node VMAC = 555555555555
• Hub UUID = d759ae79-a710-444f-b5cc-490f20d34200
• Node证书UUID与Hub UUID一致

已验证的正常流程 #

• TLS握手全链路正常（Certificate → CertificateVerify → Finished 步骤无异常）
• WebSocket升级请求得到HTTP/1.1 101 Switching Protocols响应
• Hub日志明确输出“SC-1-HF … CONNECTED”

异常现象 #

WebSocket升级完成后，Azbil节点立刻发送TLS警告帧：

TLSv1.3 Record Layer: Alert (Level: Warning, Description: Close Notify)

Src  192.168.20.241:49158  →  Dst  192.168.20.27:4443
Re-assembled TCP Data (hex):
17 03 03 00 13 F7 C8 47 DB 06 25 06 AB 06 0F B2 ...

已完成的排查动作 #

✓ VMAC配置无冲突（Hub/Node分别为66…/55…）
✓ Node证书内部状态字段（268）显示正常(0)
✓ Node端Hub VMAC字段（274）配置正确
✓ Node端Hub UUID字段（275）配置正确
✓ Hub已导入CA证书（iss-1.pem）并完成Node证书验证
✓ 两端系统时钟同步正常

1. Close Notify警报的含义 #

TLS 1.3里的Close Notify是主动关闭会话的标准通知，属于警告级别而非错误。这里的情况是Azbil节点在WebSocket升级完成后，主动触发了TLS会话关闭——不是握手失败，而是会话建立后节点侧有未满足的连接条件，或者配置校验没通过。

2. 下一步排查方向 #

结合BACnet/SC协议规范和Azbil HeloPLA固件的特性，建议从这几个点入手：

(1) 检查WebSocket子协议协商结果

BACnet/SC强制要求WebSocket升级请求必须携带Sec-WebSocket-Protocol: bacnet-sc子协议头。

• 抓包确认Hub返回101响应时，是否同步返回了Sec-WebSocket-Protocol: bacnet-sc字段；
• 如果Hub没正确返回这个字段，节点会因为协议不匹配直接断开。

(2) 验证BACnet/SC初始化帧的交互

WebSocket升级完成后，Hub必须立刻发送BACnet/SC初始化帧（包含Hub的VMAC、UUID等标识），节点验证通过后才会保持连接。

• 抓包看Hub在返回101响应后，有没有发送BACnet/SC应用层的初始化帧；
• 如果Hub没发这个帧，Azbil节点会在超时后发送Close Notify并断开。

(3) 导出Azbil节点的固件日志

通过HeloPLA软件导出节点的系统日志，重点找WebSocket/TLS相关的错误信息：

• 尤其关注证书UUID匹配、VMAC校验、BACnet/SC协议版本兼容的日志条目；
• 部分Azbil固件会直接在日志里标注断开原因，比如“未收到初始化帧”“UUID校验失败”。

(4) 确认TLS 1.3加密套件兼容性

检查两端协商的TLS 1.3加密套件是否在Azbil固件的支持列表里：

• Azbil HeloPLA 2.0的SC固件对ECC加密套件有特定要求，必须是TLS_AES_256_GCM_SHA384或TLS_AES_128_GCM_SHA256；
• 可以通过抓包查看TLS握手的Server Hello帧，确认协商的加密套件。

(5) 检查Hub的bacnet-sc-reference-stack配置

• 确认Hub配置里是否启用了BACnet/SC的WebSocket服务端模式，且正确绑定了VMAC和UUID；
• 查看Java栈的详细日志，有没有“初始化帧发送失败”“协议解析错误”这类隐性错误。

内容的提问来源于stack exchange，提问作者siddhesh wani