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:
@@ -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)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user