felhom.eu/documentation/audits/SPIKE-lan-discovery-2026-07-18.md

SPIKE — R-6: LAN service discovery from the guest (SSDP · WSD · mDNS · SMB) — 2026-07-18

STATUS: COMPLETE (objective legs) — verdict below. One human leg (S4.4 Explorer render) is PENDING Viktor and the samba+wsdd stack is intentionally left live for it. Empirically maps which Docker network mode inside the appliance LXC can send AND receive each LAN discovery protocol on the real household LAN, proves the negative for the default bridge, and stands up a real samba+wsdd stack that a Windows 11 client discovers and mounts. No production code shipped; every live mutation is a spike--prefixed throwaway container or a /tmp script, inventoried in §CLEANUP. The verdict matrix is the architecture input R-7 (SMB) and R-8 (DLNA) were gated on.

Class: SPIKE (empirical; no product code). Repos touched: felhom.eu (this doc + the ROADMAP R-6 row only). felhom-agent / felhom-controller read-only for the premise.

1. Baselines (verified at session start, git HEAD)

Repo	live main @	spec-brief expected @	Version	Delta
felhom.eu	9e13ead	ee4e061	hub v0.66.0 / scripts v1.20.0	docs/iso-out-path commits since the brief (07-18)
felhom-agent	f222a7b	8208a80c	v0.90.0	docs-only build-root-move commit (07-18)
felhom-controller	ac13966	a4a7de3d	v0.143.0	build.sh path repoint (07-18)

The deltas vs the brief are all the 2026-07-18 "DooPlex build root moved off SSD" doc/path commits; none touch the guest-network premise. Premise re-confirmed LIVE in S0, not from memory.

2. Probe topology (all four actors on one L2, 192.168.0.0/24)

Actor	IP	Role
Appliance guest LXC 9201 (demo-vm-felhom)	192.168.0.127	probe target — responders live here
DooPlex (192.168.0.180)	192.168.0.180	scripted Linux LAN peer
Windows 11 workstation	192.168.0.110	the REAL client (WSD/mDNS/SMB probes + Explorer)
felhom-pve host / vmbr0	192.168.0.162	read-only bridge facts only

---

VERDICT (one paragraph)

The appliance guest IS LAN-bridged and multicast discovery works from it — but ONLY when the responder shares the guest's network namespace (guest-direct or a Docker --network host container). Docker's default bridge cannot receive LAN multicast at all, so WSD and mDNS discovery are dead there while a published unicast port still works. Empirically, guest-netns (S1) and host-network (S2) are byte-for-byte equivalent and pass SSDP/mDNS/WSD in both directions; the default bridge (S3) fails multicast RX for all three. A real samba + wsdd stack on host-network is discovered by Windows 11 (ProbeMatch confirmed), answers on TCP 445, and serves an authenticated read/write SMB round-trip. A real SSDP MediaServer:1 advertisement from host-network is received by both LAN clients. Recommendation for R-7: run the samba/wsdd stack as a host-network infra stack, LAN-bound. For R-8: Jellyfin's built-in DLNA is physically viable on this topology if it runs host-network. One caveat R-7/R-8 must carry: vmbr0 runs with multicast_snooping=1 and no STP — it worked here because the household router (.1) is an active IGMP querier, but a customer LAN with snooping-on-and-no-querier could prune the groups (§7d).

---

S0 — live topology facts (GATE PASSED)

# pct config 9201
features: nesting=1,keyctl=1
net0: name=eth0,bridge=vmbr0,hwaddr=BC:24:11:9F:70:B4,ip=dhcp,type=veth
unprivileged: 1

# pct exec 9201 -- ip -4 addr show eth0
2: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 192.168.0.127/24 brd 192.168.0.255 scope global dynamic eth0

# vmbr0 (host /etc/network/interfaces)
iface vmbr0 inet static
    address 192.168.0.162/24
    bridge-ports enp1s0
    bridge-stp off
# /sys/class/net/vmbr0/bridge/multicast_snooping => 1

# pct exec 9201 -- ss -lntu | grep -E ':(445|139|1900|5353|3702|5357) '  => ports free

Confirmed: guest holds its own DHCP lease on the household /24 (same subnet as the workstation and DooPlex), eth0 carries the MULTICAST flag, all six target ports are free. Premise HOLDS. Anchor caveat recorded: vmbr0 multicast_snooping = 1, STP off — the querier-dependence risk the matrix must settle.

S1 — raw multicast matrix, guest netns directly (no Docker)

Responder python3 /tmp/spike-mcast.py <proto> in pct exec 9201; probers on DooPlex (.180) and the workstation (.110), multicast egress pinned to each host's LAN IP (IP_MULTICAST_IF).

Protocol	guest RX (responder logged probe)	guest TX (prober got unicast reply)
SSDP 239.255.255.250:1900	PASS (both probers)	PASS (both probers)
mDNS 224.0.0.251:5353	PASS	PASS
WSD 239.255.255.250:3702	PASS	PASS

Evidence (SSDP, representative):

[probe .180] GOT REPLY from 192.168.0.127:1900 :: b'SPIKE-REPLY proto=ssdp from=responder'
[probe .110] GOT REPLY from 192.168.0.127:1900 :: b'SPIKE-REPLY proto=ssdp from=responder'
[guest RX]  from 192.168.0.180:48169 :: 'M-SEARCH * HTTP/1.1 ...'  -> [TX] replied unicast
            from 192.168.0.110:64537 :: 'M-SEARCH * HTTP/1.1 ...'  -> [TX] replied unicast

Finding: all three pass in both directions despite multicast_snooping=1 on vmbr0 — no querier-absence pruning observed on this LAN (see §7d for why, and the BYO risk).

S2 — same matrix from a Docker --network host container in the guest

Responder in docker run --network host … python:3-alpine. Result: identical to S1 — all PASS. Host netns = guest netns, proven not assumed.

Bonus corroboration (mDNS leg): the host-net responder also logged unsolicited real LAN mDNS reverse-lookup queries from the router 192.168.0.1 (…192.168.0.162.in-addr.arpa … QTYPE PTR) — independent proof the container genuinely receives live LAN multicast, not just our own probes.

S3 — the negative proof: default bridge + -p published ports

Same responder, docker run --network bridge -p <port>:<port>/udp ….

Protocol	multicast RX across bridge	unicast → published port (192.168.0.127:<port>)
SSDP 1900	FAIL (container never logged the M-SEARCH — see note)	PASS (both probers)
mDNS 5353	FAIL ([NO REPLY] 3s timeout)	PASS
WSD 3702	FAIL ([NO REPLY] 3s timeout)	PASS

The container's own log shows only the unicast datagrams, never the multicast probe — the multicast simply never crosses the docker bridge. The port-publish itself works, so the failure is specifically multicast, exactly the negative R-7 needs.

SSDP note (a tell-tale, not a pass): the SSDP multicast probe did get a reply — but from 192.168.0.1:1900 with ST: upnp:rootdevice, USN: uuid:e4c7…, i.e. the household router's real UPnP IGD answering the broadcast M-SEARCH, NOT our container (whose log confirms it never received the datagram). Recorded as FAIL for the container; the stray reply is corroboration that the M-SEARCH genuinely propagated on the LAN while the bridged container stayed deaf to it.

S4 — the real thing: samba + wsdd (host network), Windows 11 client

Throwaway host-network stack in the guest: spike-samba (alpine + apk add samba, share spike-share on a /tmp-backed dir, user spikeuser, throwaway password — NOT a real secret, disable netbios=yes, smb ports=445) and spike-wsdd (alpine + apk add wsdd, wsdd -i eth0 -4 -H 4 -n FELHOM-SPIKE -w WORKGROUP). Listeners confirmed: udp 192.168.0.127:3702, tcp 192.168.0.127:5357, tcp 0.0.0.0:445.

Leg	Method	Result
1. WS-Discovery ProbeMatch	scripted Probe (Types=wsdp:Device) from the workstation	PASS — ProbeMatch from 192.168.0.127; wsdd logged our exact MessageID from 192.168.0.110
2. Port 445 reachability	Test-NetConnection 192.168.0.127 -Port 445	PASS — TcpTestSucceeded: True
3. SMB round-trip	New-SmbMapping as spikeuser → write roundtrip.txt → read back → byte-compare	PASS — BYTE-COMPARE: PASS; dir listed README.txt (24B) + roundtrip.txt (28B)
4. Explorer Network view (human)	Viktor: Explorer → Network shows FELHOM-SPIKE, double-click opens the share	PENDING — human leg; stack left live

wsdd log for leg 1:

08:32:29 joined multicast group 239.255.255.250 on 192.168.0.127%eth0 ; scheduling Hello
08:32:44 192.168.0.110:55639(eth0) - - "Probe urn:uuid:aaaaaaaa-...-000000000001 UDP" - -

The scripted client's friendly-name auto-fetch reported FAIL only because python-wsdd's metadata HTTP endpoint (:5357/<uuid>/) requires the native WS-Discovery Resolve→Transfer/Get handshake that Windows Explorer performs itself (a direct throwaway Get 404s). The objective discovery gate is the ProbeMatch (PASS); the FELHOM-SPIKE name is what wsdd is configured to present and is the subject of the human leg. Optional S4.5 (mDNS .local name + phone) was skipped.

S5 — SSDP / DLNA pre-check for R-8 (scripted only)

Host-network responder advertising urn:schemas-upnp-org:device:MediaServer:1, answering only that ST (so a reply can't be the router IGD). Device-specific M-SEARCH from DooPlex and the workstation:

[.180] reply from 192.168.0.127:1900 felhom-spike=True :: HTTP/1.1 200 OK ... SERVER: FelhomSpike/1.0
[.110] reply from 192.168.0.127:1900 felhom-spike=True :: HTTP/1.1 200 OK ...
[responder] RX M-SEARCH ST='...MediaServer:1' from .180 -> replied ; from .110 -> replied

PASS from both clients; the router did NOT answer (it is not a MediaServer). A DLNA advertisement physically reaches clients on this LAN. No Jellyfin/catalog touched — R-8 owns the real-media validation.

S6 — macvlan fallback

NOT RUN — conditional on S2 failing, and S2 PASSED. Host-network fully satisfies the requirement, so the macvlan-on-veth-in-unprivileged-LXC path was not needed. Left as a documented fallback if a future deployment must avoid host-network port collisions (§7c).

---

7. Verdict matrix + prose

Protocol / mode	guest netns (S1)	docker host-net (S2)	docker bridge+publish (S3)	macvlan (S6)
SSDP 1900 RX / TX	PASS / PASS	PASS / PASS	FAIL / n-a · unicast-publish PASS (router-IGD false reply)	not run
mDNS 5353 RX / TX	PASS / PASS	PASS / PASS	FAIL / FAIL · unicast-publish PASS	not run
WSD 3702 RX / TX	PASS / PASS	PASS / PASS	FAIL / FAIL · unicast-publish PASS	not run
SMB 445 unicast	n/a	PASS (S4)	publish PASS	not run
Explorer visibility (human)	n/a	PENDING (S4.4)	n/a	not run

(a) Recommended transport for the R-7 SMB stack — HOST-NETWORK, LAN-bound. The matrix is unambiguous: WSD (Windows Explorer's actual discovery) and mDNS require the responder in the guest netns; the default docker bridge is categorically deaf to LAN multicast. So samba + wsdd (and any avahi) must run network_mode: host. Bind SMB to the LAN interface only; never expose 445 over the tunnel (the LAN-only rule R-7 already states). This is the expected outcome — and the matrix, not the expectation, now backs it.

(b) R-8 "try Jellyfin built-in DLNA first" — PLAUSIBLE on this topology. SSDP MediaServer:1 adverts physically reach both LAN clients (S5). The only structural requirement carried over from (a): Jellyfin's DLNA server must also run host-network to send/receive SSDP — the same constraint, not a new one. The cheap path is worth trying before adding minidlna.

(c) Bridge/snooping caveat for R-7's spec. Two things must appear in the R-7 spec: (i) host-network binds 445 / 3702 / 5357 directly on the guest's LAN IP — the appliance owns those ports; a customer running a second SMB/WSD service on the box would collide (macvlan is the escape hatch, untested here); (ii) the multicast-snooping dependency below.

(d) Open question for BYO topologies — NOT tested, named as a doc-level gap. Everything here was measured on the operator's own household LAN, where vmbr0 has multicast_snooping=1 but the router (.1) is a live IGMP querier + UPnP IGD, so groups are not pruned. Two untested risks for real customers: (i) a customer LAN with snooping on and no querier could prune SSDP/mDNS/WSD groups — discovery would silently fail even though this spike passed; (ii) Peti's BYO cluster bridge is unknown — a BYO guest may sit on an isolated/routed bridge with no L2 path to the household LAN, where discovery is impossible regardless of network mode. R-7/R-8 specs should require a per-deployment "discovery reachability" check (a snooping/querier probe) rather than assuming the appliance result generalizes.

NOT tested (explicit)

• Explorer Network render (S4.4) — human leg, pending Viktor; stack left live.
• macvlan (S6) — not needed (host-net passed).
• Real DLNA client / TV rendering actual media — R-8 owns.
• Phone mDNS .local resolution (optional S4.5) — skipped.
• BYO bridge topology (Peti's arc) — untested by design; §7d gap.
• IPv6 discovery — probes were IPv4-only (wsdd -4).
• Customer LAN with snooping-on + no-querier — the §7d structural risk; not reproducible on this LAN.
• SMB signing / large-file throughput / multi-user — R-7 owns.
• wsdd friendly-name via direct HTTP Get — 404 without the native Resolve handshake; Windows does it natively.

CLEANUP

Throwaway containers spike-hostnet-*, spike-bridge-*, spike-ssdp-ms and all guest-netns responder processes were docker rm -f / pkill'd at the end of each leg. Intentionally left live for the S4.4 human leg: spike-samba + spike-wsdd (host-network), share \\192.168.0.127\spike-share as FELHOM-SPIKE. Teardown one-liner once Viktor confirms Explorer:

ssh felhom-pve "pct exec 9201 -- docker rm -f spike-samba spike-wsdd; \
  pct exec 9201 -- rm -f /tmp/spike-*.py /tmp/spike-*.sh /tmp/spike-*.log"
ssh kisfenyo@192.168.0.180 "rm -f /tmp/spike-probe.py /tmp/spike-msearch.py"

Then pct exec 9201 -- docker ps -a | grep spike must be empty. The demo box is wiped in the upcoming rehearsal regardless, but this leaves it report-clean.