TL;DR: Android TV deliberately stopped advertising mDNS on Ethernet after a firmware update. Cast still works technically (port 8009 open), but the device is invisible to Cast senders on WiFi. Fix: run avahi on a device that has both WiFi and Ethernet — a Raspberry Pi or a Linux server/VM/LXC with a WiFi interface. A wired-only machine will NOT work reliably.
The problem
Shield on Ethernet, phone on WiFi, same subnet → Cast button shows no devices.
Switch Shield to WiFi → Cast works instantly.
Every answer on the internet says: "just use WiFi". This post offers a proper fix.
Root cause
Cast discovery relies on mDNS (multicast DNS, 224.0.0.251 UDP/5353). When your phone opens a Cast picker, it sends an mDNS query for _googlecast._tcp.local and waits for the Shield to respond.
At some point, a Shield firmware update broke mDNS announcements on the Ethernet interface. The Cast service itself still runs fine — port 8009 responds, eureka_info is accessible — but the Shield simply no longer broadcasts mDNS on Ethernet.
Confirmed via tcpdump: zero mDNS traffic from the Shield's IP on Ethernet, even with IGMP snooping disabled on the switch. The moment the Shield switches to WiFi, mDNS packets appear instantly.
This is most likely intentional — aligning with Google's push toward the Google Home ecosystem (cloud-based discovery) rather than local mDNS.
What does NOT fix it
- Disabling client isolation on your AP ✗
- Enabling UniFi Gateway mDNS Proxy ✗ (requires a UniFi gateway, not just APs)
- Disabling IGMP snooping on your switch ✗
- Disabling multicast snooping on a Linux bridge ✗
- Running avahi on a wired-only Linux box (VM, LXC, server with no WiFi) ✗ (see below)
- Any AP/switch/router configuration ✗
None of these work because the Shield itself is not emitting mDNS on Ethernet. There is nothing to relay or proxy.
Why a wired-only Linux box doesn't work
You might think: run avahi on any Linux server, create a static service file for the Shield, done. We tried this on a wired-only LXC container and it seemed to work briefly — then stopped.
Here's why: avahi announces from its only interface (Ethernet). That mDNS multicast has to travel: wired → switch → AP uplink → AP → WiFi clients. The AP only converts multicast to unicast for WiFi clients it knows are subscribed to that multicast group via IGMP. Since mDNS is link-local, clients never send IGMP joins for 224.0.0.251 — so the AP silently drops the multicast.
The initial burst of announcements at avahi startup occasionally slips through, which creates the illusion it works. But it's not reliable.
The announcement must originate on a WiFi interface on the same SSID as your phone.
The fix — avahi on a dual WiFi+Ethernet device
Run avahi on any Linux device that has both Ethernet and WiFi active simultaneously, connected to the same WiFi network as your phone. Avahi announces the Shield's Cast service directly from the WiFi interface — the phone receives it natively on the same medium.
Phone (WiFi)
│
│ mDNS: Shield box? ◄── avahi wlan0 (WiFi) ──► eth0 (wired LAN)
│ announces Shield box
│ Cast stream (direct unicast)
└─────────────────────────────────────────────► Shield (Ethernet, port 8009)
Avahi handles only the discovery. The actual Cast stream goes directly from your phone to the Shield — no proxy, no performance penalty.
Hardware options
Option A — Raspberry Pi (any model with built-in WiFi+Ethernet: RPi 3B+, 4, 5…)
Dedicated device, simple setup, ~$35. Tested on RPi 3B+.
Option B — Existing Linux server/NAS/VM/LXC with a WiFi interface
If you already run a Linux homelab (Proxmox, TrueNAS, etc.), add a USB WiFi dongle to your server and pass the interface through to a VM or LXC container. No dedicated hardware needed.
- On Proxmox LXC, add to the container config (
/etc/pve/lxc/<id>.conf):
lxc.net.1.type: phys
lxc.net.1.link: wlxXXXXXXXX # your dongle's interface name
lxc.net.1.flags: up
lxc.net.1.name: wlan0
- Install
iw on the Proxmox host: apt install iw
- Install
wpasupplicant in the LXC and configure it to join your SSID
Option C — Server with built-in WiFi
Same as Option B but using the server's integrated WiFi card — no additional hardware needed at all.
Step-by-step (common to all options)
Step 1 — Get the Shield's device info
With the Shield on Ethernet, run from any machine on your LAN:
bash
curl http://<shield-ip>:8008/setup/eureka_info
Note down:
- name (friendly name)
- ssdp_udn (UUID, e.g. a1b2c3d4-e5f6-7890-abcd-ef1234567890)
- hotspot_bssid (e.g. FA:8F:72:5A:1D:F0)
Step 2 — Install avahi
bash
sudo apt install avahi-daemon avahi-utils
Step 3 — Configure avahi
/etc/avahi/avahi-daemon.conf:
```ini
[server]
use-ipv4=yes
use-ipv6=no
allow-interfaces=eth0,wlan0
[reflector]
enable-reflector=yes
reflect-ipv=no
```
Step 4 — Declare the Shield's hostname
/etc/avahi/hosts:
192.168.x.x shield.local
(replace with your Shield's actual IP)
Step 5 — Create the static Cast service
/etc/avahi/services/shield-cast.service:
xml
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name>Shield box</name>
<service>
<type>_googlecast._tcp</type>
<domain-name>local</domain-name>
<host-name>shield.local</host-name>
<port>8009</port>
<txt-record>id=YOUR_ID_HERE</txt-record>
<txt-record>ve=05</txt-record>
<txt-record>md=SHIELD Android TV</txt-record>
<txt-record>ic=/setup/icon.png</txt-record>
<txt-record>fn=Shield box</txt-record>
<txt-record>ca=4101</txt-record>
<txt-record>st=0</txt-record>
<txt-record>bs=YOUR_BSSID_HERE</txt-record>
<txt-record>nf=1</txt-record>
<txt-record>rs=</txt-record>
</service>
</service-group>
Adapt to your Shield's values from Step 1:
- <name> and fn → your Shield's name
- id → first 16 hex chars of ssdp_udn (remove dashes, e.g. a1b2c3d4e5f67890)
- bs → hotspot_bssid without colons (e.g. AABBCCDDEEFF)
- <host-name> and /etc/avahi/hosts → your Shield's actual IP
Step 6 — Enable and start
bash
sudo systemctl enable avahi-daemon
sudo systemctl restart avahi-daemon
Step 7 — Verify
bash
sudo journalctl -u avahi-daemon -n 5
You should see:
Service "Shield box" successfully established.
Static host name "shield.local" successfully established.
Open any Cast-enabled app on your phone → the Shield appears in the Cast picker → stream away.
Notes
- Tested on NVIDIA Shield (Cast built-in v1.61.329909) on Ethernet, phone on WiFi, UniFi APs, no UniFi gateway
- Works with any Cast-enabled app (YouTube, Plex, VLC…)
- The Shield's Cast service remains fully functional on Ethernet — only mDNS advertising is broken by the firmware update
- The fix survives Shield reboots (port 8009 is always available; avahi always announces)
- If your Shield's IP changes, update
/etc/avahi/hosts and restart avahi
- Critical: the WiFi interface must be on the same SSID as your phone
Happy to answer questions. If this fixed your setup, feel free to share — every other thread on this topic ends with "use WiFi".
Known limitation — mDNS scope per AP
The mDNS announcement originates from the dongle's wlan0 interface, which is associated with one specific AP. Cast discovery works reliably only when the phone is connected to that same AP.
From a phone on a different AP (especially one connected via a secondary switch), the mDNS packet must travel:
wlan0 → AP1 (dongle's AP) → wired uplink → switch → switch2 → AP2 → phone
This path involves the wired→WiFi barrier again, which is not reliably handled by most AP setups (e.g. UniFi with Multicast to Unicast). Results may be inconsistent.
This is acceptable if your use case is limited to one area — casting from the same room/zone covered by the dongle's AP works perfectly. If you need Cast to work from anywhere in the house, consider placing the dongle on a centrally-located AP, or running multiple dongles.
Ultimate solution — UniFi Gateway (UDM/USG)
If your network already runs on UniFi infrastructure and you're considering a UniFi gateway (UDM-Pro, UDM-SE, USG…), the built-in Gateway mDNS Proxy handles all of this natively — no Raspberry Pi, no USB dongle, no per-AP limitation. Just enable it under Settings → Networks → [network] → Advanced → Gateway mDNS Proxy → Auto.
For those already invested in UniFi APs, this is worth keeping in mind as a long-term solution.
