DD-WRT and Chromecast: default WLAN to LAN bridge blocks UDP?

8,278

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
Share:
8,278

Related videos on Youtube

victoid
Author by

victoid

Updated on September 18, 2022

Comments

  • victoid
    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
      NetworkKingPin about 8 years
      Try 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
      Daniel B about 7 years
      This isn’t about UDP. It’s about multicast. Sadly, multicast is still somewhat problematic with WiFi networks today.
  • victoid
    victoid over 10 years
    Thanks for the suggestion. Tried it... no change.
  • victoid
    victoid over 10 years
    Thanks 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.