NET-NOTES: one-console-at-a-time (netnub -p single session); Mac vs .NET conflict

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-09 18:26:22 -05:00
co-authored by Claude Fable 5
parent 6a595cc565
commit ee7f680f79
+11
View File
@@ -464,6 +464,17 @@ blamed before the real bug fell out. Findings, in the order they mattered:
- Manual mission-N start in the same DOSBox: `32rtm.exe -x` (saying
"resident" is fine) then `netnub -p -f btl4opt > nn.log`; TSRs and SET
env persist from the autoexec.
- **ONE CONSOLE AT A TIME (2026-07-10):** `netnub -p` listens for a SINGLE
console. With both generations able to reach the pod (Mac 4.10 via
tap2_mirror + host .NET via SendToRxAdapters), whoever connects FIRST owns
it; the other's SYN goes unanswered = "doesn't see the pod". Seen live: Mac
couldn't connect while the .NET TeslaConsole held an ESTABLISHED
200.0.0.1->.113:1501 session. FIX: quit the unused console, wait the pod's
~60s loop for a fresh netnub, bring up the other. Diagnose:
`Get-NetTCPConnection -RemoteAddress 200.0.0.113` (owning process) + a wire
sniff -- the Mac's 52:54:00:e7:3e:f0 emits NOTHING if it lost its `ether
tap` binding or Console 4.10 isn't polling (a DIFFERENT failure than the
session conflict).
## Console 4.10 between-missions behavior — characterized (2026-07-09 session 2)