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 — verdict below. All legs incl. the human Explorer leg PASSED; stack torn down, box report-clean (§CLEANUP). 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 + FELHOM-SPIKE renders in Explorer), 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. But the human leg exposed a second requirement wsdd alone does not meet (S4b): the Explorer double-click on FELHOM-SPIKE failed with 0x80070035 because the flat name resolved by no path — WSD gives visibility, not name resolution. Adding nmbd (NetBIOS name service) fixed it live (\\FELHOM-SPIKE then resolves and mounts). Recommendation for R-7: run the stack host-network, LAN-bound — smbd + wsdd (visibility) + nmbd (flat-name resolution), and ideally avahi/.local for modern clients. 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	SPLIT then RESOLVED: device VISIBLE (WSD PASS); double-click FAILED 0x80070035 with wsdd-only → after the S4b nmbd fix, Viktor's double-click opened spike-share and README.txt (screenshot) — full one-click UX PASS

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. Optional S4.5 (mDNS .local name + phone) was skipped.

S4b — the Explorer double-click failure (THE sharpest R-7 finding)

Viktor's human leg surfaced a split result Windows-side that the by-IP scripted tests had masked:

• Visibility: PASS. Explorer → Network → Computer renders FELHOM-SPIKE (wsdd/WSD works as a discovery beacon — screenshot on file).
• Double-click: FAIL → Windows cannot access \\FELHOM-SPIKE · 0x80070035 "network path not found."

Diagnosis from the workstation (192.168.0.110) isolates the cause as flat-name resolution, not SMB:

Check	Result
Test-NetConnection 192.168.0.127 -Port 445 + New-SmbMapping \\192.168.0.127\spike-share	PASS — mounts by IP, lists files. SMB/auth/445 are fine.
Resolve-DnsName FELHOM-SPIKE (DNS)	fail — "DNS name does not exist"
Resolve-DnsName FELHOM-SPIKE -LlmnrNetbiosOnly	fail — timeout (nobody answers LLMNR)
ping FELHOM-SPIKE	"could not find host"
nbtstat -A 192.168.0.127	"Host not found" — no NetBIOS name service (disable netbios=yes)

Root cause: WSD hands Explorer a device icon named FELHOM-SPIKE, but the double-click issues a plain UNC \\FELHOM-SPIKE, whose flat name Windows must resolve via DNS → LLMNR → NetBIOS. With disable netbios=yes and no mDNS/LLMNR responder, nothing answers → 0x80070035. Mounting by IP bypasses all name resolution and works — proving the SMB server itself is healthy.

Fix verified live (S4b relaunch: samba with disable netbios=no + nmbd):

Check (after nmbd)	Result
nbtstat -A 192.168.0.127	FELHOM-SPIKE <00>/<03>/<20> Registered
ping FELHOM-SPIKE	Reply from 192.168.0.127 — flat name resolves via NetBIOS broadcast
New-SmbMapping \\FELHOM-SPIKE\spike-share	MOUNT BY NAME: OK — lists the share
Viktor re-tried the Explorer double-click	PASS — Network → FELHOM-SPIKE → spike-share opened; README.txt ("hello-from-felhom-spike") displayed. The full visible-and-openable one-click UX now works.

Conclusion for R-7: wsdd alone makes the box visible but is not sufficient for the one-click UX — a flat-name resolver is required for \\FELHOM-SPIKE to open. Options, in order of how well they serve the exact WSD-shown flat name:

1. nmbd / NetBIOS name service (samba's disable netbios=no + run nmbd) — directly resolves the flat \\FELHOM-SPIKE, proven here. The catch: NetBIOS-over-TCP is legacy (Microsoft is slowly deprecating it) and can be off on hardened client networks; needs UDP 137/138 and interfaces = eth0 + bind interfaces only = yes in production (nmbd bound the docker 172.x bridges too here — must be pinned to the LAN iface).
2. mDNS / avahi advertising felhom-spike.local — Windows 10/11 resolve .local natively and it is the future-proof path, but it serves \\felhom-spike.local\…, not the flat name the WSD icon double-clicks — so it's an additional access path, not a drop-in fix for the Explorer double-click. (Not tested live — R-7 should.)
3. Accept "mount by IP / by .local" and treat WSD as visibility-only — the weakest UX.

R-7 recommendation: ship wsdd + nmbd (LAN-bound) for the classic one-click experience and avahi/.local for the modern clients, so both the flat name and .local resolve.

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	PASS — FELHOM-SPIKE renders (S4.4)	n/a	not run
Explorer double-click → open share	n/a	FAIL w/ wsdd-only → PASS w/ nmbd (S4b)	n/a	not run

(a) Recommended transport + services for the R-7 SMB stack — HOST-NETWORK, LAN-bound, THREE daemons. The matrix is unambiguous on transport: WSD (Explorer's actual discovery) and mDNS require the responder in the guest netns; the default docker bridge is categorically deaf to LAN multicast. So the stack must run network_mode: host, SMB bound to the LAN interface only, never over the tunnel. On services, S4b proved wsdd is not enough: ship **smbd (445) + wsdd (WSD visibility)

• nmbd (NetBIOS flat-name resolution, so the Explorer double-click on \\FELHOM-SPIKE actually opens) + ideally avahi (.local for modern/Apple clients)**. Pin every daemon to the LAN iface (interfaces = eth0 + bind interfaces only = yes) — nmbd otherwise also binds the docker 172.x bridges. Without nmbd/mDNS the box is visible but not openable by name (0x80070035).

(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)

• mDNS / avahi .local as a flat-name/.local resolver alternative to nmbd (S4b option 2) — NOT tested; R-7 should validate \\felhom-spike.local on Win11 + Apple/phone clients.
• LLMNR responder as a third name-resolution path — not tested (client LLMNR is on, but nothing on the box answered it).
• 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

TORN DOWN — report-clean verified 2026-07-18 (after Viktor's Explorer PASS). All throwaway containers (spike-hostnet-*, spike-bridge-*, spike-ssdp-ms, spike-samba, spike-wsdd) removed and every guest-netns responder process killed; /tmp/spike-* deleted on both the guest and DooPlex. Verified:

pct exec 9201 -- docker ps -a --filter name=spike-   => (none)
pct exec 9201 -- ls /tmp/spike-*                     => (none)
pct exec 9201 -- ss -lntu | grep :(445|3702|5357|137|139)  => (free)
DooPlex ls /tmp/spike-*                              => (none)

No systemd units, no compose files, no controller-visible stacks were ever created. Note: nmbd bound the docker 172.x bridge subnets too during S4b — a production R-7 stack must set interfaces = eth0 + bind interfaces only = yes.