SCADA Things

← Articles
LangEN한국어
SECS/GEM/7 min read/— views

HSMS Active vs Passive: Which Side Dials, and What Happens When Neither Does

Connection refused in 3 ms, or a TCP session where nothing ever arrives. Real captures that tell the two HSMS mode mistakes apart.

SECS/GEMMESSCADATroubleshootingChecklists

The equipment engineer says HSMS is up. Your host log fills with connection refused every 3 ms. Or the worse version — TCP connects, then nothing arrives, a timer burns down, and the socket closes. Both look enough like a firewall problem to send you to the network team. Usually the real answer is that the two sides disagree about which one dials. SEMI E37 splits connection mode into Active and Passive, and that is a different axis from Host versus Equipment. This is where the hours go.

Sorting an HSMS session that never opens: does the TCP connection succeed, and does the tool log an RX of Select.req — two checks that separate both-sides-passive from both-sides-waiting The session never opens Does TCP connect? no Both sides are Passive connection refused yes Any Select.req RX logged? no Each side waits for the other TCP up · no RX yes Pairing is right — it's Select Select Status

Active/Passive is a different axis from Host/Equipment

In E37 the passive entity waits for a TCP connection on a known port; the active entity opens it. That is the whole distinction. Which of the two is the host and which is the tool has nothing to do with the choice.

Equipment passive and host active is the common pairing in the field, but it is not a rule. Some lines are wired the other way, and vendors inside the same fab disagree. So don't fill in the configuration from "the tool is usually the listener". On one link, exactly one side is passive.

There are only two ways to get it wrong, and they produce completely different symptoms.

  • Both sides passive — nobody dials. There is no listener on the port, so the peer is refused at the TCP stage.
  • Both sides active — both dial at the peer's port. No listener either, so refused again. If one side happens to have a listener up anyway, TCP connects and then goes quiet.

Every capture below came from hitting the simulator's listener from outside, over a real socket, in this run.

When the pairing is right

The equipment side is passive on 5501; the host is active and dials.

TCP  connect 127.0.0.1:5501
TX Select.req    00 00 00 0A 00 0B 00 00 00 01 00 00 06 01
RX Select.rsp    00 00 00 0A 00 0B 00 00 00 02 00 00 06 01
TX Linktest.req  00 00 00 0A 00 0B 00 00 00 05 00 00 06 02
RX Linktest.rsp  00 00 00 0A 00 0B 00 00 00 06 00 00 06 02
TX Separate.req  00 00 00 0A 00 0B 00 00 00 09 00 00 06 03
   (no reply; the peer closed the socket)

SType is the sixth byte of the header: 01 is Select.req, 02 Select.rsp, 05/06 the Linktest pair, 09 Separate.req. The fourth byte of Select.rsp — the Select Status — is 00, and SessionID 00 0B and SystemBytes 00 00 06 01 came back unchanged. That is a session in SELECTED.

The order is the part that matters. The side that opened the TCP connection is the side that sent Select.req. The equipment side only answered.

When TCP connects and nobody sends Select

Same listener, TCP connection only — the host-side process sent nothing and waited six seconds.

2026-08-26T00:02:45.034Z  TCP  connect 127.0.0.1  (equipment log)
   ... 6.4 s with no RX and no TX ...
2026-08-26T00:02:51.441Z  TCP  connect 127.0.0.1  (the next capture's connection)

The equipment's packet log holds one TCP connect line and nothing after it. The passive side does not send Select.req first. What this capture verifies is that listener's behaviour — but it is exactly the picture on your screen when the host is configured to wait for the peer to open the session: TCP ESTABLISHED, HSMS NOT SELECTED, nothing in the log.

The timer that cleans this up is T7, the limit from TCP connect to reaching SELECTED. When T7 expires the connection should be dropped, and an implementation that doesn't will sit holding the zombie socket. The three timers are laid out side by side in a tool that answers Linktest but never completes Select.

When it never connects at all

Listener stopped, same port dialled.

connect 127.0.0.1:5501 → [Errno 111] connection refused  (0.003 s)

Three milliseconds. Not a timeout — an immediate answer. And the attempt leaves no trace in the equipment log at all: this run's export has only the two SERVER entries where the listener went down and came back, with nothing between them. The TCP handshake never completed, so there was nothing for the application to see.

That is what makes it useful for sorting. If the tool's log shows no connection attempt, the problem is below HSMS: wrong port, listener not started, a firewall, or that side is configured active too.

A slow timeout instead of an immediate refusal is a different story. A refusal means you reached the peer host; a silent timeout usually means something in between dropped the packets.

Three lines, in order

  1. Is the connection refused immediately? Then there is no listener on that port. Put both configurations side by side and check that exactly one says passive.
  2. Does the tool's log show a TCP connect? No means a path problem. Yes means you got that far.
  3. Is there a Select.req RX after it? No means both sides are waiting for each other. Yes, with no session, means the pairing is right and it's time to read the Select Status — that single byte is covered in an accepted Select and a refused one.

Check the retry interval while you're in there. A refusal is usually instant, so a reconnect loop can spin hundreds of times a second. E37's T5, connect separation, exists to stop exactly that.

Reproducing it

All three captures came from driving the passive listener in the SECS/GEM simulator from outside, over a real socket. Start the listener and attach your host as active, then switch your host to passive as well — the second and third pictures above show up as they are.