vwemirror/TeslaRel410
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

NET-NOTES: host-side console bridging WORKING (bridge IP + Npcap SendToRx)

Browse Source 
Windows host apps can now talk to the pod directly: static 200.0.0.1/24
on the Network Bridge adapter plus the Npcap SendToRxAdapters registry
value for the bridge GUID (driver-start read, so bounce the npcap
service and relaunch the pod). Verified with a host TCP connect to
200.0.0.113:1501. Documented the trade (pod frames go up to the host
stack INSTEAD of out to the TAP members -- SheepShaver console is deaf
while set), the revert, and the future both-at-once fix (Npcap >=1.83
user-mode DLLs + a second per-handle MODE_SENDTORX send handle in the
fork's pcap backend). Groundwork for the TeslaSuite .NET console
driving the DOSBox pod.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-09 10:44:45 -05:00
co-authored by Claude Fable 5
parent a1c3363f0b
commit 384418f385
1 changed files with 34 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
emulator/NET-NOTES.md
+34 -9
View File
@@ -499,16 +499,41 @@ Live A/B runs with the wire watcher (net_loop.conf pod, three missions):
is not starvation -- DWM background-window throttling suspected.
Backlog.
## Modern console on the HOST — bridging plan (2026-07-09, in progress)
## Modern console on the HOST — WORKING (2026-07-09, verified TCP connect)
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
Host (TeslaSuite .NET console) <-> pod on the same machine. Verified:
`Test-NetConnection 200.0.0.113 -Port 1501` connects with source
200.0.0.1. Recipe (both steps elevated):
1. Host IP on the bridge (no gateway -- only 200.0.0.x routing changes):
`New-NetIPAddress -InterfaceAlias 'Network Bridge' -IPAddress
200.0.0.1 -PrefixLength 24`
2. Npcap SendToRx so pod (pcap-injected) frames reach the host stack --
without it the host's ARP gets no answer (neighbor stays Incomplete;
hairpin-tested: injected frames provably never reach the local
stack). The per-handle MODE_SENDTORX API needs Npcap >= 1.83
user-mode DLLs (our wpcap.dll/Packet.dll predate it; npcap.sys is
1.88 and has the registry side), so use the driver-level value:
```
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\npcap\Parameters' `
-Name SendToRxAdapters -Value '\Device\{5DB5521D-2D56-40E8-9E3D-3B36C9EE7C8F}' -Type String
Stop-Service npcap -Force; Start-Service npcap
```
Value = semicolon-separated `\Device\{bridge GUID}` entries (parser:
NPF_GetRegistryOption_AdapterName, npcap Packet.c); read ONCE at
driver start (hence the service bounce); relaunch the pod after (its
pcap handle dies with the driver).
**THE TRADE: while SendToRxAdapters covers the bridge, ALL Npcap
injections on it are indicated as receives INSTEAD of transmits** --
pod frames reach the host stack but no longer reach the TAP members, so
**the SheepShaver Mac console is DEAF while this is set** (and wire-
injection diagnostics can't reach the pod either; pod RX is unaffected).
Revert: `Remove-ItemProperty ... -Name SendToRxAdapters` + service
bounce + pod relaunch. PROPER BOTH-AT-ONCE FIX (future): upgrade Npcap
user-mode DLLs to >=1.83 and patch the fork's pcap backend to mirror
every send onto a second handle set to per-handle MODE_SENDTORX --
frames then go out to the TAPs AND up to the host. Host
connect/disconnect churns netnub (exit + ~60s relaunch) -- expected.
## Open questions / notes