diff options
| author | Luke Hoersten <[email protected]> | 2026-06-14 12:31:05 -0500 |
|---|---|---|
| committer | Luke Hoersten <[email protected]> | 2026-06-14 12:31:05 -0500 |
| commit | 8d740665777af6d74b334e2dee98a53ebb9a29aa (patch) | |
| tree | 5d8268862f8305f791769aca4a71965b9bdec0ea /main/display.c | |
| parent | 14c94c7e9e90322d5486100687c5096213ab04db (diff) | |
M1: link-loss & recovery verified 2026-06-14
Real production failure mode for PoE-only deployments: a switch
reboot or briefly down VLAN yanks Ethernet without cutting power.
Confirmed the device handles it cleanly (no panic, no reset, no
state loss) and re-acquires DHCP on link-up.
Serial trace from the bench:
W (748316) net_eth: link down # cable pulled
I (916316) net_eth: link up, mac e8:f6:0a:e0:90:94 # plugged back in
I (924816) net_eth: got ip 10.0.13.83 ... # DHCP renewed ~8.5s later
Same boot throughout — uptime kept climbing past the disconnect, no
ESP reset. The HTTP server stayed bound and the mDNS responder task
kept running through the outage; both resumed serving the moment
DHCP came back. free_heap and free_psram identical to pre-disconnect
(no leak from the cycle).
TESTING.md M1 entry now captures this with the actual log line
sequence. The integration-suite "Cable pull mid-frame" item gets a
✅ for the idle/no-Scrypted variant; the actual mid-frame Scrypted
variant still pending.
Diffstat (limited to 'main/display.c')
0 files changed, 0 insertions, 0 deletions