raphael
5baf3f4dc7
Wireshark's built-in HSMS dissector — written by network-protocol authors who don't know us, didn't talk to us, and don't share implementation details with secsgem-py — is a third independent codec for our framing. If they parse our pcap without warnings, our HSMS framing is wire-correct independently of both our internal tests and the secsgem-py interop path. interop/tshark_validate.sh: - Boots secs_server on 127.0.0.1:5099 (away from the demo port) - Captures the loopback wire traffic with tcpdump - Runs secs_client through ~24 transactions plus Separate.req + TCP FIN - Parses the pcap with tshark -V using the HSMS dissector - Asserts: no "Malformed Packet", no "Dissector bug", at least one HSMS frame, expected tokens present (Select.req/rsp, Separate.req, Data message), reports histogram (count by control type + distinct S/F pairs) Result against the demo: 69 HSMS frames dissected, 49 distinct S/F pairs (S01F01..S16F28), all clean. Dockerfile gains tshark + tcpdump. .gitea/workflows/ci.yml gains a `tshark-dissector` job that runs this validator as part of every push to main. README proof table grows to 6 commands. VERIFICATION.md §1a documents a follow-up: round-trip the KAT fixtures through secsgem-py to corroborate that the format codes we used match an independent implementation. Strengthens the KAT proof from "internally consistent" to "confirmed by a second implementer who read the spec without talking to us." Plan: VERIFICATION.md §2. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
secsgem-py interop harness
Cross-validates our C++ SECS-II / HSMS / GEM implementation against secsgem-py 0.3.0, the de-facto Python reference. Everything runs in Docker — no Python or secsgem-py on the host.
What it tests
| Driver | Peer | Coverage |
|---|---|---|
host_vs_cpp_server.py |
C++ secs_server (passive) |
HSMS select/separate, S1F1/F3/F11/F17/F23, S2F13/F17/F29/F33/F35/F37/F41, S5F3/F5/F7, S5F1 unsolicited, S6F11 unsolicited, S7F3/F5/F19, S10F1/F3, S1F15 |
secs_interop_probe (C++) |
passive_equipment.py (secsgem-py GemEquipmentHandler) |
HSMS select, S1F13/F14, S1F1/F2, S1F3/F4, clean separate |
raw_gem300_harness.py |
C++ secs_server (passive) |
GEM 300 streams secsgem-py upstream doesn't ship: S3F17/F18 (E87 carrier action), S16F5/F6 (E40 PRJobCommand), S16F27/F28 (E94 CJobCommand) — built with custom SecsStreamFunction subclasses + registered custom DataItems |
24 named checks on the C++-server side; 4 explicit checks on the C++-host side; 4 GEM-300 raw-frame checks. Implicit HSMS state-machine and wire-level framing validation everywhere.
Running
# Start C++ passive server, then drive it with secsgem-py host:
docker compose up -d server
docker compose run --rm interop python3 /app/interop/host_vs_cpp_server.py \
--host server --port 5000 --session-id 0
# Start Python passive equipment, then probe it with the C++ host:
docker compose up -d equipment_py
docker compose run --rm builder /app/build/secs_interop_probe \
--host equipment_py --port 5000 --device 0
Both exit 0 on success.
What this caught
Real bugs surfaced by interop (now fixed):
- Strict U4 parsing rejected U1-encoded identifiers. SEMI E5
declares DATAID, RPTID, VID, CEID, ALID, EXID, etc. as
U1 | U2 | U4 | U8; secsgem-py picks the smallest width that fits. Ouras_u4_scalar,as_u2_scalar, etc. were strict. Now lenient with range-checked downcasts (messages_helpers.hpp::any_unsigned_first). - PPBODY rejected when sent as ASCII. SEMI lets PPBODY be
ASCII | Binary | List; secsgem-py defaults to ASCII. Added theBINARY_OR_ASCIIcodegen item type plus a permissiveas_text_or_binaryaccessor, used for S7F3/F6. - Missing S1F23 / S1F24 (Collection Event Namelist). Added the
wire schema in
data/messages.yaml, avids_for(ceid)accessor on the event-report store, and the dispatch handler insecs_server.cpp. - Missing S10F3 handler (Terminal Display Single, host→equipment). Our server only registered S10F1; per SEMI E5, S10F1 is equipment→host and S10F3 is the host→equipment counterpart. Added the missing dispatch.
The C++ test suite still passes (278 cases / 1436 assertions) after each of these changes — the fixes are purely permissive widenings, no existing behaviour was broken.