From e3d04d64592b84a96dd5cc3fc0b14835b5fc7438 Mon Sep 17 00:00:00 2001 From: Arti Zirk Date: Fri, 30 Oct 2026 16:03:19 +0200 Subject: [PATCH] NETWORK_REPORT: correct 64.3 -- the Ethernet Port Error banner is a clean-boot condition The terminal shows 'Ethernet Port Error - 24' after a clean boot while its port works, so it is the firmware's own Ethernet self-test result (which also fails in MAME per LANCE_LOOPBACK_REPORT), not damage from the payload. Consequences: the banner is not evidence about the takeover, and the 'needs a power cycle' claim now rests only on the runs that crashed; for the REST=0x0073 build the network was never checked after the run. --- harness/mame/NETWORK_REPORT.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/harness/mame/NETWORK_REPORT.md b/harness/mame/NETWORK_REPORT.md index 38a527b..0adfa83 100644 --- a/harness/mame/NETWORK_REPORT.md +++ b/harness/mame/NETWORK_REPORT.md @@ -4349,3 +4349,34 @@ layout: the text row `REST` sits at y 846-867 and the box at y 850-874, so they overlap. The text panel already reports `OK YES/NO`, so both indicator boxes (`ok` at x 120 and TX-done at x 160) have been removed. Cosmetic only — the values in 64.1/64.2 are unaffected. + +## 65. Correction: "Ethernet Port Error - 24" is a clean-boot condition + +Section 64.3 used the banner `Ethernet Port Error - 24` on the screen behind the +panel as evidence that the firmware's network driver had been left broken by the +payload. **That is wrong**: the terminal shows this banner after a **clean boot** +as well, while its Ethernet port works normally (the unit answers ping and the +rdebug service on port 771). + +So the banner is the firmware's own **Ethernet self-test result**, not a runtime +fault. It is worth noting for the LANCE work that this matches the emulator: the +firmware's `C - LANCE TEST` also fails in MAME (`LANCE_LOOPBACK_REPORT.md`, the +`RMD1_FRAM` mismatch), while ordinary traffic passes. In other words the +self-test's expectation is not met by this hardware either — pre-existing, and +unrelated to the takeover payload. + +### 65.1 What that changes + +* The banner is **not** evidence about the payload. Section 64.3's conclusion + ("the driver noticed the chip disappear and marked the port failed") is + withdrawn. +* The claim "a takeover run costs a power cycle" therefore rests only on the + runs that **crashed** (the `0x23CC50` write and the marker/`.text` overlap). + For the current build — the one that produced `REST = 0x0073` — the unit was + never pinged after the run, so **end-to-end recovery is unverified**, not + disproved. +* The check is one command, after a successful (non-crashing) run: + +```sh +ping -c3 -W2 100.103.100.103 +```