Levandor

telep-tv AirPlay undiscoverable on Wi-Fi — root cause is the box's 10G switch port, NOT 5 GHz

6 min read

telep-tv (the telep-mainframe uxplay AirPlay receiver) never shows up in the AirPlay / Screen-Mirroring list on Wi-Fi clients — and the long-standing “5 GHz cross-band client isolation” blame is wrong. Proven 2026-08-30: the box advertises mDNS correctly on the wire, but the router’s switch does not flood multicast that arrives on the box’s 10G port out to the Wi-Fi interface. Unicast is unaffected, so ssh/ping/mDNS-resolve/AirPlay-connect all work — only multicast-based discovery fails.

For Agents

Host/receiver: telep-mainframe = telep-tv, 192.168.1.123, MAC d8:5e:d3:a7:05:d6, single NIC enp5s0 negotiated at 10000 Mbps. Runs uxplay + avahi. Client: the Mac, 192.168.1.113, on Wi-Fi phy0-ap0. Router: telep-router OpenWrt, 192.168.1.1, br-lan, multicast_snooping=0 (floods), no flow_offloading, no packet_steering. Bridge fdb ports: box on br-lan port 2 = a 10G link; HP printer on port 5 = 1G lan; Mac on port 11 = phy0-ap0 (Wi-Fi). The tell: wired 1G devices (printer) reach Wi-Fi via multicast; the box on the 10G port does not. Band-independent (failed on 2.4 GHz AND 5 GHz) ⇒ NOT the 5 GHz cross-band isolation issue. NOT multicast_to_unicast, NOT a Mac mDNS cache, NOT band — all three tried and ruled out.

Symptoms

  • telep-tv never appears in the AirPlay / Screen-Mirroring picker on Wi-Fi clients (Mac, historically blamed on “5 GHz”).
  • Historically assumed to be the router’s “5 GHz cross-band client isolation” bug (see the correction below).
  • From the Mac, casting/connecting would work if only it could be discovered — because unicast to the box is fine.

Investigation (2026-08-30) — what was actually proven

1. The box advertises correctly ON THE WIRE

tcpdump on the box’s enp5s0 shows telep-tv’s _airplay._tcp + _raop._tcp mDNS going out as multicast to 224.0.0.251, with the full TXT record:

model=AppleTV3,2   features=0x527FFEE6   srcvers=220.68

So avahi/uxplay are healthy and emitting real multicast onto the LAN. (This is a different failure from 2026-08-30-telep-tv-mdns-vanishes-after-uxplay-restart, where avahi had silently dropped the records — here the records are present and on the wire.)

2. Unicast works from the Mac, browse does not

From the Mac (192.168.1.113, 5 GHz Wi-Fi):

dns-sd -L "telep-tv@telep-mainframe" _airplay._tcp   # RESOLVES fine (unicast)
ping 192.168.1.123                                   # OK
ssh levander@192.168.1.123                           # OK
dns-sd -B _airplay._tcp                              # NEVER shows telep-tv (browse = what Control Center uses)

dns-sd -B (browse) is exactly the multicast-driven discovery Control Center relies on — and it never sees telep-tv. dns-sd -L (resolve) is unicast and works. So the failure is specifically the multicast path, not name resolution or reachability.

3. The Mac’s multicast reception is fine — only the box’s doesn’t arrive

Fresh browses from the Mac (services chosen so nothing else dedupes/caches them):

  • _ipp._tcp → finds the wired HP printer (on a 1G port). So the Mac does receive wired-origin mDNS multicast.
  • _nut._tcp → finds nothing from telep-mainframe (this service is only advertised by the box; nothing else masks it). So the box’s multicast specifically never reaches the Mac.

⇒ The Mac’s multicast receive path is healthy. The box’s multicast is being dropped somewhere between the box’s port and the Wi-Fi port.

4. Band-independent → kills the 5 GHz theory

The discovery failure reproduced on both 2.4 GHz and 5 GHz. A band-specific radio/isolation cause cannot explain a failure that survives switching bands.

5. Router bridge topology isolates the variable

On telep-router (192.168.1.1), the br-lan forwarding database:

DeviceMACbr-lan portLink
box (telep-mainframe)d8:5e:d3:a7:05:d6port 210G (enp5s0 @ 10000 Mbps)
HP printer—port 51G lan
Mac—port 11phy0-ap0 (Wi-Fi)

Bridge multicast_snooping=0 (so it floods multicast, not snoops). No flow_offloading on the firewall, no packet_steering configured. The only difference between the printer (reaches Wi-Fi) and the box (doesn’t) is which physical switch port they land on: 1G port vs 10G port.

Root cause

The router’s switch does not flood multicast that arrives on the box’s 10G port out to the Wi-Fi interface. Devices on 1G ports (the printer) reach Wi-Fi clients via multicast; the box on the 10G port does not. Unicast is unaffected — which is exactly why ssh, ping, dns-sd -L resolve, and AirPlay connect all work, while multicast-based discovery (dns-sd -B, Control Center) fails. The box has a single 10G NIC and no spare 1G port.

Correcting the old "5 GHz cross-band client isolation" assumption

The AirPlay-discovery symptom was for months attributed to the router’s 5 GHz cross-band client isolation bug. That attribution is wrong for AirPlay discovery. The cross-band isolation issue (see Problem 3 — Wi-Fi cross-band client isolation (driver-level)) is real but is a separate wifi↔wifi unicast problem affecting the Bambu printer. The telep-tv discovery failure is a wired(10G-port)→Wi-Fi multicast-flooding problem, is band-independent, and does not involve cross-band isolation at all.

Tried and ruled out

TriedResult
multicast_to_unicast=1 on both SSIDs (telep1_5, telep1_2)No change — reverted both to 0 (baseline). Not an m2u problem.
Mac mDNS cache flush / full Wi-Fi toggleNo change — not a Mac cache problem.
2.4 GHz vs 5 GHzFails on both — not band-specific.

Fix options (none applied yet)

  1. Move the box cable to a 1G LAN port — quickest confirm + fix. Loses the 10G link. Proves the theory instantly (printer on 1G reaches Wi-Fi, so the box on 1G should too).
  2. Keep 10G + run an mDNS reflector/proxy. Pin uxplay to fixed AirPlay/RAOP ports, then run an always-on mDNS proxy/reflector on a Wi-Fi- or 1G-attached host (or on the router) that re-advertises telep-tv’s _airplay._tcp/_raop._tcp at the box’s IP:port. Wi-Fi clients then discover it via the proxy and connect over unicast (which already works).
  3. Investigate the router DSA switch multicast-to-CPU behavior for the 10G port — why multicast ingressing the 10G port isn’t forwarded to the CPU/other ports for flooding. Possibly a per-port multicast-flood / mrouter setting or a DSA/hardware quirk on the 10G interface.

Graph View

Backlinks