HSMS 连接总失败？排查这 5 个配置点

"HSMS 连接失败，是 SECS/GEM 调试中最常见、也最浪费时间的问题。经常是 MES 那边一切正常，设备厂商说没问题，EAP 日志里却全是 Timeout或 Connection refused，中间到底卡在哪？"

HSMS（High-Speed SECS Message Services）是 SECS/GEM 的 TCP/IP 实现，本质上就是"设备作为服务器，EAP 作为客户端，先建 TCP，再建 HSMS，最后建 SECS 通信"。听起来简单，但任何一个环节配错，连接都会失败。

这篇文章我把最常见的 5 个踩坑点列出来，附带排查命令和日志特征。如果你也遇到连不上的情况，按这个顺序查一遍，通常能定位问题。

一、先理解 HSMS 的三层握手

排查之前，先知道正常的连接流程长什么样：

第一层：TCP 连接

设备端（Equipment）作为 Passive，监听固定端口（通常是 5000）。
EAP 端（Host）作为 Active，发起 TCP 连接。

第二层：HSMS 选择

TCP 连上后，EAP 发 Select.req，设备回 Select.rsp。
只有两边都同意，HSMS Session 才算建立。

第三层：SECS 通信建立

EAP 发 S1F13（建立通信请求），设备回 S1F14（同意）。
然后 EAP 发 S1F1（Are you there?），设备回 S1F2（I am here）。

到这里，"电话"才算真正打通。下面这 5 个配置点，分别对应这三层里最容易出错的地方。

二、踩坑点 1：IP 和 Port 配错了

现象： EAP 日志里出现 Connection refused 或 Connection timeout，连 TCP 都建不起来。

排查方法： 在 EAP 服务器上，先用最基础的网络命令确认连通性：

复制代码

# 第一步：ping 设备 IP
ping 192.168.1.10

# 第二步：确认端口是否监听
telnet 192.168.1.10 5000

如果 ping 不通，先找网络工程师查 VLAN 或网线。如果 ping 得通但 telnet 连不上，大概率是设备端的 HSMS 端口没开，或者端口不是 5000。

我踩过的坑： 有一次设备厂商给的文档里写的是端口 5000，但设备实际监听的是 5001。原因是设备软件升级后端口变了，文档没更新。我用 nmap 扫了一圈端口才找到：

bash

复制

复制代码

nmap -p 5000-5010 192.168.1.10

Checklist：

设备 IP 地址是否正确？
端口号是否与设备实际监听的一致？
设备端 HSMS 服务是否已经启动？

三、踩坑点 2：Active / Passive 模式搞反了

现象： TCP 能连上，但 EAP 发 Select.req 后没收到 Select.rsp，或者设备端日志显示"收到了未知的 Select.req"。

排查方法： HSMS 规定了两端角色：

Passive（设备端）：监听端口，等待连接。
Active（EAP 端）：发起连接。

如果 EAP 配成了 Passive，设备配成了 Active，两边都在等对方连过来，结果就是"互相等，永远连不上"。

确认方法： 查看设备端的配置界面或配置文件，确认 Connect Mode 是 Passive（有的设备叫 Server 或 Equipment）。EAP 端配置文件中确认 mode = Active（或 mode = Host）。

我踩过的坑： 有一次新设备进厂，默认模式是 Active（因为设备厂商在自家工厂测试时用的这个模式）。EAP 按常规配置去连，连了一小时都没成功。最后发现是设备端模式没切过来。

Checklist：

设备端是 Passive / Server / Equipment 模式？
EAP 端是 Active / Host 模式？
两边不是同一个模式？

四、踩坑点 3：防火墙或交换机 ACL 拦截

现象： ping 能通，telnet 端口也能通，甚至 TCP 握手都能完成，但 Select.req 发出去后石沉大海，或者回包被截断。

排查方法： 这种情况通常是网络层策略问题。半导体工厂的网络通常分好几层：办公网、生产网、设备网，中间有防火墙或交换机 ACL。

分两步查：

确认 EAP 服务器到设备 IP 的端口是否开放

bash

复制
复制代码
```
nc -zv 192.168.1.10 5000
```
在 EAP 服务器上用 Wireshark 抓包 过滤条件：tcp.port == 5000 看 TCP 三次握手是否完成，以及 Select.req 是否发出、是否有 Select.rsp 回包。

常见场景：

防火墙只放行了 TCP 连接，但长时间无数据的会话被自动断开。
交换机端口配置了端口安全（Port Security），MAC 地址不匹配直接丢包。

我踩过的坑： 某次调试，白天能连上，晚上连不上。后来发现是工厂的网络策略：晚上办公网到生产网的路由被切换，新的路由路径上没有放开 5000 端口。这种"时好时坏"的问题最难查。

Checklist：

网络策略是否允许 EAP 服务器访问设备 IP 的指定端口？
是否有会话超时机制导致长时间空闲后断开？
抓包确认 Select.req 是否发出、Select.rsp 是否收到？

五、踩坑点 4：T5 / T7 超时参数不匹配

现象： TCP 能连，HSMS Select 也能完成，但 EAP 发 S1F13 后收不到 S1F14，或者收到了但被认为是超时。

排查方法： HSMS 定义了多个超时参数，最常见的是：

T5 ：等待 Select.rsp 的超时时间（默认 10 秒）
T7 ：TCP 连接建立后等待 Select.req 的超时时间（默认 10 秒）

如果设备端的 T5 设的是 5 秒，EAP 端的 T5 设的是 10 秒，本身不影响连接。但如果中间网络延迟较高（比如跨楼层或跨 VLAN），EAP 在 10 秒内没收到 Select.rsp，就会主动断开连接。

查看日志特征： EAP 日志里看到：

plain

复制

复制代码

Select.req sent
...（10秒后）...
Select Timeout - Connection closed

而设备日志里显示：

plain

复制

复制代码

Select.req received
Select.rsp sent

但设备日志里的时间戳比 EAP 超时时间晚。

解决方法： 两边对一下超时参数，通常保持默认即可。如果是跨厂区或网络延迟大的环境，可以适当调大 T5 和 T7。

Checklist：

EAP 端和设备端的 T5、T7 参数是否一致？
网络延迟是否超过 T5 设定值？

六、踩坑点 5：Session ID 或 Device ID 不匹配

现象： TCP 通了，Select 也过了，但 EAP 发 S1F13 后设备回 S1F14 的拒绝码，或者设备根本不认这个 Session。

排查方法： HSMS 的 Select.req 里有一个字段叫 Session ID （有的设备叫 Device ID）。EAP 发起的 Select.req 里的 Session ID 必须和设备端期望的值一致。

典型场景：

设备端期望 Session ID = 0（默认值）
EAP 端配置成了 Session ID = 1（因为该 EAP 要同时管理多台设备，想给每台设备分配不同 ID）

如果设备端没做配置，它只认 0。EAP 发 1 过去，设备可能直接拒绝。

查看日志： 设备端日志里如果有 Session ID mismatch 或 Invalid Session ID，就是这个原因。

解决方法： 先确认设备端是否支持非 0 的 Session ID。如果不支持，EAP 只能配成 0。

Checklist：

EAP 端配置的 Session ID 是否与设备端一致？
设备端是否支持多 Session？

七、一个快速排查流程图

如果你遇到连不上的情况，按这个顺序查：

ping 设备 IP → 不通？找网络。
telnet 设备端口 → 不通？检查端口和设备服务。
确认 Active/Passive 模式 → 搞反了？改配置。
Wireshark 抓包 → 有 TCP 没 HSMS？查防火墙和超时参数。
对 Session ID → 前面都对但 S1F14 拒绝？查 Session ID。

HSMS 连接问题 90% 是网络配置问题，10% 是协议参数问题。遇到连接失败，不要急着改代码，先用 ping、telnet、nc 和 Wireshark 确认底层连通性。底层不通，上层代码写得再好也没用。

基于这些经验，我整理了一份《SECS/GEM调试手册》，有需要的朋友可以交流。