From a1c3363f0b8a2e608b90d5e4b0aa945942ad9b8f Mon Sep 17 00:00:00 2001 From: Cyd Date: Thu, 9 Jul 2026 10:24:17 -0500 Subject: [PATCH] NET-NOTES: console between-missions behavior characterized + host bridge plan Three-mission live session on net_loop.conf: the pod side is fully retail-faithful (netnub auto-relaunches on mission end AND console disconnect, ~60s cycle). Console 4.10's between-missions dead-end is app-level: its TCP receives FIN+RST from the fresh netnub yet the app never re-queries; only an app relaunch (endpoints rebuilt from the INI) recovers it. Selecting a printer in the Chooser makes the app launch much faster (Printing Manager stalls without one) but does not change the dead-end. Documented the working operator rhythm and the plan for bridging the host-side .NET console onto the pod LAN (bridge adapter IP 200.0.0.1/24, possible Npcap SendToRx for pod->host hairpin). Co-Authored-By: Claude Fable 5 --- emulator/NET-NOTES.md | 46 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/emulator/NET-NOTES.md b/emulator/NET-NOTES.md index e5a50e1..e74133e 100644 --- a/emulator/NET-NOTES.md +++ b/emulator/NET-NOTES.md @@ -465,6 +465,52 @@ blamed before the real bug fell out. Findings, in the order they mattered: "resident" is fine) then `netnub -p -f btl4opt > nn.log`; TSRs and SET env persist from the autoexec. +## Console 4.10 between-missions behavior — characterized (2026-07-09 session 2) + +Live A/B runs with the wire watcher (net_loop.conf pod, three missions): + +- **net_loop.conf VERIFIED: the pod is fully retail-faithful.** netnub + auto-relaunches after mission end AND after a console disconnect (both + observed); full cycle back to ready ~60s including the ~30s SBK + re-upload. Four unattended relaunches in one evening, zero touch. +- **Console 4.10 endpoint dead-end — precisely characterized:** after a + mission ends, the console's TCP retries its old session, the fresh + netnub answers FIN then RST (so the app's stack KNOWS the session died + and a live pod is at ready) -- and the app never issues another query. + Clicking around the UI (new mission, network toggles) does NOT re-arm + it; only relaunching the app does (endpoints rebuild from the INI / + stationery at launch). Stationary.ini = the master stationery: full + 26-cockpit roster with per-endpoint params (openTimeout=10, + queryTimeout=60, loadQueryInterval=1, inProgressQueryInterval=10). +- **PRINTER: select one.** With no Chooser selection the app stalls on + Printing Manager calls (much slower launch; the old 'nilP' throw at + BTFAConsoleDoc.cp:117 is doc-init printing). A serial printer spooled + to file makes the app launch much faster. It does NOT fix the + mission-end dead-end (no print job is even attempted at mission end -- + spool stays empty). +- **Operational rhythm that works:** fly mission -> pod recycles itself + -> relaunch the Console app (fast with a printer selected) -> select + pod -> ready. Under two minutes of operator time per turnaround. + Deep fix would be PPC reverse-engineering of the endpoint state + machine; deferred -- the modernized .NET TeslaConsole is the long-term + driver. +- Cosmetic: VDB head windows (pentapus MFDs/radar) go choppy while + DOSBox is unfocused and smooth when focused; total CPU was 14% so it + is not starvation -- DWM background-window throttling suspected. + Backlog. + +## Modern console on the HOST — bridging plan (2026-07-09, in progress) + +To let a Windows-host app (TeslaSuite .NET console) talk to the pod: +give the **Network Bridge adapter** a static host IP `200.0.0.1/24` +(no gateway; only 200.0.0.x routing changes). Host->pod already proven +(host-stack frames appear in pod-side pcap). Pod->host may need Npcap's +**SendToRx** per-adapter option (pcap-injected frames are normally not +indicated up to the host stack on the same adapter -- the classic +DOSBox-pcap guest<->host limitation); verify with a TCP connect to +200.0.0.113:1501 and add the option only if needed. Note: a host +connect/disconnect churns netnub (exit + ~60s relaunch) -- expected. + ## Open questions / notes - Exact TCP listen port(s) — not in the source grep; get from NETNUB.EXE or a capture at milestone 3.