SCADA Things

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

S1F13 Came Back With COMMACK 0 on a Socket That Was Never Selected

A capture where Linktest, S1F13 and S1F1 all got answered before Select.req was ever sent, and what SEMI E37 says should have happened.

SECS/GEMMESSCADATroubleshooting

Against the simulator every host test passed. On the first real tool, the opening S1F13 never gets an answer and dies on T3. The equipment log has one Reject line, or just a dropped connection. There is one place in the host code worth suspecting here: did it write a data message without waiting for Select.rsp? Below is a capture of doing exactly that on purpose. I opened a socket, skipped Select, and sent Linktest.req, S1F13 and S1F1 in that order. All three were answered. The Select.req I sent last got its Select.rsp. So everything before it crossed the wire while the session was NOT SELECTED.

Linktest.req, S1F13 and S1F1 answered on a socket still in NOT SELECTED, with Select.req and Select.rsp arriving only afterwards to reach SELECTED HostEquipment NOT SELECTED Linktest.req Linktest.rsp S1F13 S1F14 COMMACK 0 S1F1 S1F2 Select.req Select.rsp SELECTED

The capture

One socket, in the order sent. Only what the equipment side logged as RX is reproduced.

TX Linktest.req   00 00 00 0A 00 0B 00 00 00 05 00 00 02 01
RX Linktest.rsp   00 00 00 0A 00 0B 00 00 00 06 00 00 02 01

Length 10, SessionID 00 0B (11), bytes 2 and 3 zero, PType 0, and SType 05 for Linktest.req. The answer is SType 06 with SystemBytes 00 00 02 01 echoed back. It looks like a healthy link — except this socket has not been through Select once.

TX S1F13 W=1      00 00 00 0C 00 0B 81 0D 00 00 00 00 02 02 01 00
RX S1F14          00 00 00 37 00 0B 01 0E 00 00 00 00 02 02
                  01 02 21 01 00 01 02
                  41 15 56 58 2D 39 30 30 30 20 50 6C 61 73 6D 61 20 45 74 63 68 65 72
                  41 0D 53 45 43 53 47 45 4D 2D 31 2E 34 2E 31

Byte 2 of the request is 81: top bit is the W-bit, the remaining seven bits are Stream 1. Byte 3 0D is Function 13. The body 01 00 is a zero-length List. Unpack the S1F14 body and 01 02 opens a two-element List holding 21 01 00 — a one-byte Binary with value 0. That is COMMACK 0. Then MDLN VX-9000 Plasma Etcher and SOFTREV SECSGEM-1.4.1.

TX S1F1  W=1      00 00 00 0C 00 0B 81 01 00 00 00 00 02 03 01 00
RX S1F2           00 00 00 32 00 0B 01 02 00 00 00 00 02 03
                  01 02 41 15 ... 41 0D ...

S1F1 went through as well. Byte 2 comes back as 01 because a reply carries the W-bit cleared.

TX Select.req     00 00 00 0A 00 0B 00 00 00 01 00 00 02 04
RX Select.rsp     00 00 00 0A 00 0B 00 00 00 02 00 00 02 04

That is the last exchange. SType 01 answered by SType 02, byte 3 00, Select Status 0. Until this line the session was not SELECTED, and the six lines above it are all bytes that moved before it.

What E37 actually allows

SEMI E37 splits an HSMS connection into NOT CONNECTED and CONNECTED, and splits CONNECTED again into the NOT SELECTED and SELECTED substates. A fresh TCP connection sits in NOT SELECTED. Only a Select.req answered by a Select.rsp with Select Status 0 moves it to SELECTED. In HSMS-SS, SELECTED is the one substate where data messages are exchanged, and Linktest belongs there too.

When a data message arrives in NOT SELECTED, E37's answer is not to service it. The defined refusal is Reject.req (SType 7), with the reason riding in byte 3. I have not verified the reason number for "entity not selected" against a tool — the equipment above never sends Reject.req at all. If you need the number, read it out of E37 directly rather than from here.

NOT SELECTED does not last forever either. E37 defines T7, the Not Selected Timeout: TCP is up, but if Select does not complete inside it, the equipment drops the connection. That is the usual culprit behind "it connects and then disconnects immediately" on the host side.

So is the capture wrong?

The equipment side is being permissive. That listener takes an SType 0 frame straight to its reply table without consulting the HSMS state. As a learning tool that is not a bad trade — you can throw one S1F13 at it and read real bytes without getting the Select handshake right first. The cost is that host code written against that permissiveness breaks the first time it meets a tool. Code that writes the next message without waiting for Select.rsp stays green in the simulator forever.

There is a second split hiding here. E30's COMMUNICATING and E37's SELECTED are different state machines, and the capture above reached COMMUNICATING without ever being SELECTED. The opposite case — SELECTED but not COMMUNICATING, so S1F3 comes back as S1F0 — is worked through in bytes in Your HSMS session is SELECTED and S1F3 still comes back as S1F0.

What to check in the host code

  • Are data messages dequeued after Select.rsp arrives? Writing S1F13 from inside the connect() callback is the most common version of this bug.
  • Does the code read byte 3 of the Select.rsp? Anything other than 0 is a refusal, and nothing more should go down that socket.
  • Does it compare the Select.rsp SystemBytes against the Select.req it sent? If they differ, that reply is not yours.
  • When Reject.req (SType 7) comes back, does the code log it instead of discarding it as an unknown frame? That one line saves half a day.
  • If the connection drops with no reply right after connecting, suspect T7. Shortening the retry interval will not fix it.

The capture reproduces on the public simulator as-is: open a socket, skip Select, send S1F13. SECS/GEM simulator.