Skip to content

Handoff — 2026-08-07

Where the XMSG/COSMOS work stands, what changed today, and the one thing that needs Ronny.

Suite: 720 green across 9 projects. Build clean, no XML doc warnings. Branch: 5000x. Everything committed.

1. The one thing waiting on you

SUPERSEDED 2026-08-08 — do not act on this section. It asks for a command that DOES NOT EXIST: there is no DEFINE-LINK / DEFINE-SYSTEM-LINK anywhere in the COSMOS guides. The real answer was the opposite of adding something — an ADJACENT system (one on the far end of your own cable) needs a DEFINE-REMOTE-NAME and no route at all; only NON-adjacent systems get a DEFINE-SYSTEM-ROUTE (COSMOS Operator Guide ND-30.025.02 section 2.5.4).

With that applied, both D100 and D103 now reach our node (A: *->19999), and the INNAK still arrives and turns out to be harmless — it was never the blocker this section assumed it was. DEFINE-FRIEND-SYSTEM is not the gate either: both machines report * No friend exists * and D100 accepts INITs anyway.

Read DOC/SUBTYPE-17-INIT-REJECT-2026-08-07.md steps 7, 8 and 9 instead. Section 4 below is kept only as the elimination record.

Original text, wrong, kept for the record:

Define or start a LINK toward our system on D100 (and/or D103). Not a route — a link.

Both machines refuse our network initialisation with INNAK, and every other explanation has been eliminated (section 4). DEFINE-SYSTEM-ROUTE told them "to reach 19999, go this way"; nothing has told them "19999 is the machine on the other end of this line". That is the only surviving hypothesis and the test changes a real machine's configuration, so it was left alone.

Also still yours, unchanged: the HDLC defects in nd100x and RetroCore reported earlier (oversized-frame handling, silent drops, the odd-Displacement byte/word mismatch in RetroCore).

2. What works now that did not this morning

Thing State
Relay carries transit PROVEN. Two datagrams D100 → D103 crossed our node, re-marked and forwarded out the correct link.
XFGSM (MON 200B fn 47) Implemented. Was recorded for months as "blocked on evidence"; it is documented in the version-L manual, just not in Appendix A.
XSLIN, XSECS/XSDCS Request builders + XmsgLinkInformation reply model.
All 256 SINTRAN error codes Imported with ND's text and disposition.
XMSG/XROUT error dispositions Imported from NDIX — retry/give-up per code.
23 generation variables Decoded from the parity-encoded file, then CONFIRMED against the live kernel.
X-MESSAGE 210373L manual OCR'd and imported to Installation/Installation-Description/ND-210373L-EN.md.

Bugs fixed today, in rough order of severity:

  1. BadRequest was SINTRAN error 3 = "END OF FILE". A client refused mid-read was told the file ended normally — its read loop would stop and report success. Silent data loss, and it was live. All three chosen FA status codes were wrong; now 129 / 211 / 97.
  2. XmsgFrameBuilder.Build() never computed header word 6 — the seventh site of the fabrication that once killed D100 with ERROR CODE 24. It fabricated by omission, which is why the sweep missed it. Test-only exposure, but a loaded gun.
  3. The relay never announced itself, so neither peer registered us at the XMSG level even with the link Active. Then the announce was once-only, so a link bounce left us permanently unknown.
  4. A stale topology route put node 103 on both relay links; AddLink re-points duplicates at whichever registered last, so D103 traffic would have gone out of the D100 link.
  5. Malformed XML in a doc comment (unbalanced <para>), invisible because test projects generate no documentation file.

3. Machine state as I left it

STALE as of 2026-08-08. A Windows reboot wiped both machines' XMSG kernel tables (system table down to the local entry, zero links) — the XROUT NAME table survived, so LIST-NAMES looks healthy while nothing works. Since then D100's RetroCore.ini has had its two HDLC listen ports SWAPPED (HDLC 1 now on 10364, HDLC 2 on 10362; originals commented in place, backup RetroCore.ini.bak-2026-08-08) and D100 was restarted, so D102 has lost its line to D100. Relay command: use topology-d19999-relay.json, NOT topology-d19999.json — the latter advertises node 103 as "via 100" and makes D100 report *Loop suspected*.

  • D100 (F:\RC\RonnyTest\HDLC1, terminal 9010) and D102 (HDLC2, 9102) — running, untouched except the routes below.
  • D103 (HDLC3, 9003) — running. Its RetroCore.ini HDLC line was changed to --connect=localhost:10366 so it dials OUR relay instead of D100. The old line is commented out directly above it.
  • Routes added by DEFINE-SYSTEM-ROUTE on both D100 and D103, pointing at 19999. These persist.
  • Ethernet is dead on all three — every config says --net=tcp:127.0.0.1:5010 and nothing listens on 5010. Unrelated to today's work, but worth knowing: a node must be --net=listen:5010.
  • Nothing of mine is running. No relay, no capture, no .NET hosts.

Relay command, for reference:

Xmsg.Live.Runner --config topology-d19999.json --relay-listen 10366 --relay-inbound-node 103 127.0.0.1 10364 19999 <seconds>

4. The open investigation: why INIT is refused

Full detail in DOC/SUBTYPE-17-INIT-REJECT-2026-08-07.md. Summary of what is settled:

  • Our reachability announce is INIT in SINTRAN's own vocabulary; the reply, subtype 0x17, is INNAK — an initialisation negative acknowledgement. Both names come from the Nettype column of LIST-FRAMES on the live machine.
  • Also new: the Nettype vocabulary itself — INIT, INNAK, ACK, * <->. Nothing here modelled it.

Eliminated, in order:

  1. Frame contents — markers, subtype, Flags 1, Flags 2 all identical to a real ACCEPTED INIT.
  2. Node number — re-ran the whole relay as 101; both machines NAKed identically.
  3. LAPB layer — address, control byte and sequence numbers identical to the accepted exchange (N(S)=0 N(R)=0 out, N(S)=0 N(R)=1 back).
  4. Carving — neither the XMSG kernel (23552 words) nor XROUT (39943 words) contains SAA -3, literal 177775, 0x21FE or 0x0017. The frame is assembled arithmetically; there is nothing to find.

So the peers answer at the right moment, in the right LAPB position, to a byte-perfect frame — and refuse it. What is left is peer-side knowledge, which is section 1.

Groundwork ready if carving resumes: DOC/COSMOS-RE/carve/XMSG-KERNEL-L03_flat.bin, base 0120000 VERIFIED (file word 9347 = address 142203 = XHINI), and 30 XH* handler symbols extracted from XMSG-SYMBOL-L03.SYMB.

5. Still blocked on a capture, unchanged

  • FA 0x01 / 0x04 / 0x0D — no wire layout. The carve route is CLOSED: that 1ead table is a command-NAME parser, not handler addresses. Only a capture will do it, and no client we know emits them.
  • CreateFile 0x0A — served, never driven live. COPY-FILE does not send it.
  • XFWRT (fn 43) — the last XMSG function with no source at all. A server calls it, so no terminal session will produce it.
  • The post-close XEIMA (task #18) — partly explained: ND classify it SIII_RETRY, so it means "that conversation is already gone", which fits transfers being byte-correct despite it.

DOC/PLAN-CAPTURE-SESSION-2026-08-07.md has the ordered plan, including which operator command drives which service — the version-L manual supplied that mapping.

6. Two lessons worth more than the findings

Ask the machine before carving it. Two binary carves failed to identify INNAK; one LIST-FRAMES did it in about a minute. The machine is authoritative about its own traffic and answering is free.

A number matching a constant is not proof the constant produced it. I identified Flags2 = 0xFFFD as XENIR by name-matching, downgraded it when the carve found the value in neither binary, then had it confirmed by the machine's own label. The downgrade was correct at the time even though the conclusion survived — the evidence, not the answer, is what was wrong.

7. Task list

# State
18 open post-close XEIMA — needs a capture including the close
23 open FA 0x01/0x04/0x0D + live CreateFile — needs a capture
27 open why INIT is NAKed — needs the link definition in section 1
19, 20, 21, 22, 24, 25, 26 done