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 ConnectRefresh.
  10. MP3 cast succeeds.
TopicDoc
Connect procedureConnect page
DLNA troubleshootingDLNA / streamer guide
Living-room scenarioScenarios · scenario 3
FAQFAQ