Skip to content
⌂ Home

LAN and Firewall

DLNA and AirPlay 1 casting require LAN device discovery and Renderer reachability to the ECHO host IP. Connect operations: Connect page. DLNA troubleshooting: DLNA guide.

PrincipleNotes
Same segmentECHO host and Renderer / AirPlay device on same LAN segment (usually same main router)
Discovery ≠ internetInternet access does not imply SSDP / multicast discovery works
URL reachabilityDLNA: Renderer must HTTP-fetch ECHO’s temporary URL
Private networkWindows profile should be Private; Public often has stricter firewall
┌─────────────┐
wired / Wi-Fi ─>│ Main router │<── wired (preferred) ── streamer / Renderer
└──────┬──────┘
│
wired / Wi-Fi ├── ECHO PC
│
└── other LAN devices (AirPlay speakers, etc.)
ItemRecommendation
ECHO PCMain router; wired or Wi-Fi — not guest Wi-Fi only
Streamer / RendererSame router; wired preferred
WindowsPrivate network profile
SubnetSame IPv4 segment (e.g. 192.168.1.0/24)

Often cause empty Connect list or “connected but silent renderer”:

EnvironmentTypical issue
Hotel Wi-FiClient isolation
Campus / corporateMulticast filtering, VLAN isolation
Guest Wi-FiAP isolation
Phone hotspotDevice-to-device blocked
Misconfigured MeshWireless backhaul isolation
PC on VPN, Renderer localTunnel breaks discovery or URL reach
Cascaded routers (no bridge)Double NAT, cross-segment discovery failure

Verification: On the same network, use a phone DLNA app to see if the Renderer appears. If no app sees it, fix network / Renderer before ECHO settings.

  1. Settings → Network & Internet → Wi-Fi / Ethernet → connection properties.
  2. Set profile to Private.
  3. Public profiles often block inbound access to ECHO’s HTTP URL.
  1. Windows Security → Firewall → Allow an app through firewall.
  2. Enable ECHO / Electron entries on Private networks.
  3. Briefly disable firewall for comparison only; re-enable after diagnosis.

Do not leave firewall disabled permanently. Add allow rules after identifying the cause.

Check admin UI (names vary by brand):

SettingRecommendation
AP isolation / wireless client isolationOff
Guest network isolationDo not put ECHO or Renderer on guest Wi-Fi for tests
UPnPNot required for discovery; may help some setups
Multicast / IGMP SnoopingMisconfiguration can break discovery; try disabling Snooping to compare
VLANECHO and Renderer must be mutually reachable
CaseEffectRecommendation
Full-tunnel VPNLocal traffic may enter tunnelDisable VPN for first Connect test
Split VPNRule-dependentEnsure ECHO ↔ Renderer uses local interface
System proxyUsually unrelated to DLNA discoveryLow correlation with empty list
PhaseMechanismFailure symptom
DiscoverySSDP / UPnP multicastEmpty Connect list
Casthttp://<host LAN IP>:<port>/connect/audio/...Connected, renderer silent
Remote trackECHO proxy / transcode then URLStutter, drop, timeout

ECHO picks a LAN IP based on Renderer location. Multiple NICs (Wi-Fi + Ethernet + VPN) can expose a URL unreachable from the Renderer.

See DLNA guide · found but connect fails.

Shares most LAN requirements with DLNA. Additionally:

  • Some devices are AirPlay 2–only → not supported by ECHO (AirPlay boundaries).
  • Same home-router verification applies before blaming ECHO.
  1. ECHO PC and Renderer on same main router (not guest Wi-Fi).
  2. Both IPs on same segment (e.g. 192.168.1.x).
  3. Windows profile = Private.
  4. Firewall allows ECHO on private networks (or brief disable to compare).
  5. VPN off.
  6. Router AP / guest isolation off.
  7. Renderer Media Renderer mode enabled.
  8. Phone DLNA app sees Renderer (recommended).
  9. Device appears after ECHO Connect → Refresh.
  10. MP3 cast succeeds.
TopicDoc
Connect procedureConnect page
DLNA troubleshootingDLNA / streamer guide
Living-room scenarioScenarios · scenario 3
FAQFAQ