DD-WRT and Chromecast: default WLAN to LAN bridge blocks UDP?
Solution 1
Just had an issue with this. Other reports have said disabling NAT, connecting Chromecast and then re-enabling works.
To do this go to setup > advanced routing > operatng mode and change to router mode, then connect chromecast and then switch back to gateway.
Not sure why this works, but did for me.
Solution 2
Had the same issue. I was already operating in router mode (I'm using the DD-WRT box as a WAP only), so the above didn't apply. Try enabling IPv6 support in the DD-WRT firmware.
Administration --> Management Tab
IPv6 Support... IPv6 -> enable
Some devices using DD-WRT out there require this for Chomecast to function correctly. Worked for me.
My setup:
Chromecast
v
DD-WRT as WAP
v
Cisco SG300-10 > Gateway Router
v
Wired PC
Related videos on Youtube
victoid
Updated on September 18, 2022Comments
-
victoid over 1 year
I have DD-WRT running in gateway mode on a DIR-615 I1. I've updated to the newest available build.
Chromecast is a wireless-only device, for those unfamiliar. The device has been set up and operates normally using wireless devices associated with the router, but wired ethernet devices cannot communicate with Chromecast. Specifically, the Chrome plugin says "No Cast Devices Found."
AP Isolation is disabled.
I have sniffed packets between a laptop via both wired and wireless connections and Chromecast, and this is what I've found:
There are IGMP, TCP, UDP packets between Chromecast and a wireless interface on the laptop.
There are IGMP and TCP, but zero UDP packets exchanged between Chromecast and a wired ethernet interface on the same laptop.
Specifically, the wired interface does receive the following IGMP packet from the Chromecast:
1062 55.011807 192.168.1.145 239.255.255.250 IGMP 60 V2 Membership Report / Join group 239.255.255.250
... which is also observable on the wireless interface. Some packets on the wired ethernet interface are marked as having a bad ipv4 header checksum (0x0000), but I've read this is artifactual due to checksum offloading on the NIC.
Here is the (redacted) TCP stream observable on the wired interface:
GET /ssdp/device-desc.xml HTTP/1.1 Host: 192.168.1.145:8008 Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.49 Safari/537.36 DNT: 1 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8,fr;q=0.6 HTTP/1.1 200 OK Application-URL: http://192.168.1.145:8008/apps/ Content-Type: application/xml Content-Length: 1078 <?xml version="1.0"?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <URLBase>http://192.168.1.145:8008</URLBase> <device> <deviceType>urn:dial-multiscreen-org:device:dial:1</deviceType> <friendlyName>Bedroom TV</friendlyName> <manufacturer>Google Inc.</manufacturer> <modelName>Eureka Dongle</modelName> <UDN>uuid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXX</UDN> <iconList> <icon> <mimetype>image/png</mimetype> <width>98</width> <height>55</height> <depth>32</depth> <url>/setup/icon.png</url> </icon> </iconList> <serviceList> <service> <serviceType>urn:dial-multiscreen-org:service:dial:1</serviceType> <serviceId>urn:dial-multiscreen-org:serviceId:dial</serviceId> <controlURL>/ssdp/notfound</controlURL> <eventSubURL>/ssdp/notfound</eventSubURL> <SCPDURL>/ssdp/notfound</SCPDURL> </service> </serviceList> </device> </root>
This is apparently not good enough for function, and the lack of UDP packets going in the ath0 --> eth1 (the WLAN and LAN interfaces on the DD-WRT router) direction is suspicious. Can anyone shed light on what may be happening? Bridge and route settings on the DD-WRT are all basically default.
-
NetworkKingPin about 8 yearsTry changing your channel? ive read some people having trouble with chromecast on ddwrt i use channel 11 on my ddwrt setup and my chromecast seems to never have issues. trying to throw some ideas in.
-
Daniel B about 7 yearsThis isn’t about UDP. It’s about multicast. Sadly, multicast is still somewhat problematic with WiFi networks today.
-
-
victoid over 10 yearsThanks for the suggestion. Tried it... no change.
-
victoid over 10 yearsThanks for the suggestion. IPv6 isn't apparently available with any of the DIR-615 builds, perhaps due to space constraints. There seems to be some info on getting it running, but it looks like a lot of work. My guess for why this works is that you're simply bypassing whatever routing is broken in IPv4.