[PR #140] [MERGED] fix(net): stable LAN MAC from static IP so Moonlight survives Wolf recreates #140

New issue

Closed

opened 2026-10-15 12:52:18 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:52:18 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/LXC2Docker/pull/140
Author: @JBailes
Created: 7/5/2026
Status: ✅ Merged
Merged: 7/5/2026
Merged by: @JBailes

Base: main ← Head: fix/stable-lan-mac-static-ip

📝 Commits (1)

532cadd fix(net): derive the stable LAN MAC from the static IP, not the container id

📊 Changes

2 files changed (+16 additions, -6 deletions)

View changed files

📝 internal/lxc/manager.go (+13 -3)
📝 internal/lxc/pve_tarball.go (+3 -3)

📄 Description

Symptom

After any Wolf recreate/update, Moonlight can no longer discover or connect to Wolf on its static LAN IP until you rename the host or wait out the ARP timeout. Looks like an mDNS problem; it's actually ARP.

Cause

lanMACForContainer derived the "stable" LAN MAC via stableLANMac(id) — but id is the container ID, regenerated on every recreate. So a container with a fixed gow.lan.ip (Wolf on 192.168.1.50) got a new veth MAC every recreate while reusing the IP. LAN peers/switches then hold stale ARP for that IP → the host is unreachable until the cache ages out. (stableLANMac's own doc comment calls out the Moonlight/Wolf case — the intent was right, the key was wrong.)

Fix

Key the MAC on the requested static LAN IP when present (lanip:<ip>), so the same IP always maps to the same MAC across recreates. With no static IP the address itself changes per recreate, so the id-derived MAC is unchanged.

Live-verified (pve .253, RTX 5080)

Wolf's MAC changed across recreates (02:f1:34:49:ec:9f → 02:74:68:68:f2:46), which is what silently broke Moonlight discovery through this whole debugging session. After the fix the MAC is derived from 192.168.1.50 and holds across recreates. go test ./internal/lxc/ passes.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/LXC2Docker/pull/140 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 7/5/2026 **Status:** ✅ Merged **Merged:** 7/5/2026 **Merged by:** [@JBailes](https://github.com/JBailes) **Base:** `main` ← **Head:** `fix/stable-lan-mac-static-ip` --- ### 📝 Commits (1) - [`532cadd`](https://github.com/games-on-whales/LXC2Docker/commit/532cadd2e43796761427cf49831fe90aa3304f93) fix(net): derive the stable LAN MAC from the static IP, not the container id ### 📊 Changes **2 files changed** (+16 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `internal/lxc/manager.go` (+13 -3) 📝 `internal/lxc/pve_tarball.go` (+3 -3) </details> ### 📄 Description ## Symptom After any Wolf recreate/update, Moonlight can no longer discover or connect to Wolf on its static LAN IP until you rename the host or wait out the ARP timeout. Looks like an mDNS problem; it's actually ARP. ## Cause `lanMACForContainer` derived the "stable" LAN MAC via `stableLANMac(id)` — but `id` is the container ID, regenerated on every recreate. So a container with a fixed `gow.lan.ip` (Wolf on `192.168.1.50`) got a **new veth MAC every recreate** while reusing the IP. LAN peers/switches then hold stale ARP for that IP → the host is unreachable until the cache ages out. (`stableLANMac`'s own doc comment calls out the Moonlight/Wolf case — the intent was right, the key was wrong.) ## Fix Key the MAC on the requested static LAN IP when present (`lanip:<ip>`), so the same IP always maps to the same MAC across recreates. With no static IP the address itself changes per recreate, so the id-derived MAC is unchanged. ## Live-verified (pve .253, RTX 5080) Wolf's MAC changed across recreates (`02:f1:34:49:ec:9f` → `02:74:68:68:f2:46`), which is what silently broke Moonlight discovery through this whole debugging session. After the fix the MAC is derived from `192.168.1.50` and holds across recreates. `go test ./internal/lxc/` passes. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 12:52:18 +00:00