plan: record host-side tap/bridge plumbing for the LANCE network milestone (MAME's tap is tap-mess-<uid>-0, not tap0)

This commit is contained in:
SDD committed 2026-10-16 16:17:43 +03:00
1 parent 0e2d7d9d0d
commit 7f0b2ff27c
1 file changed
+53
@@ -544,3 +544,56 @@ References: `reference/memory-space-map.md` (rows 5–6, 10 — **corrected here
`NEXT_SESSION.md` §5–6 (font path gotchas, MAC), `lat/notes/lat-receive-audit.md`
(LAT path), `docs/EK-V1000-SV-002_service-guide.txt` (levels, P3, font paths),
`docs/DTJ-1991-vol3num4_X-Window-Terminals.txt` (font daemon vs TFTP).
---
## Host-side network plumbing (for the network milestone)
Recorded 2026-10-16 from the project owner, with the interface name verified from
MAME's own source.
**MAME's tap interface is not `tap0`.** `src/osd/modules/netdev/taptun.cpp:115`
names it from the uid:
```c
sprintf(ifr.ifr_name, "tap-mess-%d-0", getuid());
```
so for uid 1000 it is **`tap-mess-1000-0`** (15 characters — right at `IFNAMSIZ`).
The provider is **`taptun`**; `networkprovider` defaults to `auto`. This build has
`taptun` and `pcap` modules present but the plan's earlier finding stands: **tap is
the usable path**.
The owner's sequence, corrected for the real name and completed:
```sh
sudo ip link add dev vt1200 type bridge # already exists (DOWN)
sudo ip link set tap-mess-1000-0 master vt1200 # NOTE: not tap0
sudo ip link set vt1200 up
sudo ip addr add 192.168.99.1/24 dev vt1200 # an address, so the host can serve
```
**Better: pre-create the tap**, so the bridge setup is done once rather than after
MAME has started:
```sh
sudo ip tuntap add dev tap-mess-1000-0 mode tap
sudo ip link set tap-mess-1000-0 master vt1200
sudo ip link set tap-mess-1000-0 up
sudo ip link set vt1200 up
sudo ip addr add 192.168.99.1/24 dev vt1200
```
`TUNSETIFF` with an existing name attaches to it, so MAME will use the one we made.
Host state as of recording: bridge `vt1200` **exists and is DOWN**; no tap device is
present yet (nothing has needed one).
**Why this matters:** the emulated terminal fetches fonts over **TFTP** (`fonts.dir`
then the PCF) — see `NEXT_SESSION.md` and `harness/serve.py` / `tools/fontgen.py`.
Bridging the tap where the host's TFTP server is reachable is what lets a font be
delivered, which is the prerequisite for the crash work. The emulated side needs
**BOOTP or a manual IP** in the same subnet.
Attaching the physical NIC to the bridge as well would give the emulated terminal
real LAN access, which the LAT/announcement work might want — not required for
font delivery, which is host-local.