Chromecast (Don't) Phone Home 👽


#1

This one is for those of you who have noticed that your Chromecast devices (and I hear many Android phones too) do a connectivity check to http://connectivitycheck.gstatic.com every minute or so.

When an internet connection goes down the Chromecast tries hits this domain tens of thousands of times, making a right mess of the Pi-Hole graphs. I’ve also decided there’s no good reason why google needs to be able to count my device pings… so I engineered a little workaround. Call it an abundance of caution.

First, set up connectivitycheck.gstatic.com as a virtual host on a local web server. I used Apache2 on another machine (I already run a bunch of local sites there) but I’m sure Lighttpd on the Pi-Hole would be great too. (You’ll need to search for instructions for how to do this for your particular favourite web server.)

In a subfolder entitled /generate_204 (Ie, served at http://connectivitycheck.gstatic.com/generate_204) simply place an index.php file containing just the following:

<?php header("HTTP/1.0 204 No Content"); ?>

And then edit /etc/hosts on your Pi-Hole to include the following line:

10.0.0.1    connectivitycheck.gstatic.com #Replace 10.0.0.1 with the IP address of the web server

And restart the Pi-Hole DNS server, either via the web interface or the terminal with

pihole restartdns

And from now on Google gets to forget about your Android devices, plus you won’t see those annoying spikes when/if your connection goes down.


#2

Wow. That is just what I need. Thanks! Too bad I’m using lighttpd and have no clue how to configure that… sigh

One question left: Do I understand correctly that the Chromecast still hits the Pi-hole server (the machine), but not Pi-hole itself (the app), as the /etc/hosts will redirect traffic without Pi-holes help?


#3

Yes indeed, the Chromecast/Android devices will hit the Pi-Hole server, but not the admin interface itself. As for creating virtual hosts with Lighttpd, there are numerous guides online that should help you with that. :grin:


#4

Need help / more details on this.

steps I used to configure this, using lighttpd:
Since we need to ensure pihole -up OR pihole -r doesn’t undo the configuration, I looked at the lighttpd configuration file, it contains a line

# Add user chosen options held in external file
include_shell "cat external.conf 2>/dev/null"

so I created /etc/lighttpd/external.conf, containing:

$HTTP["host"] == "connectivitycheck.gstatic.com" {
        server.document-root = "/var/vhosts/connectivitycheck.gstatic.com"
        accesslog.filename = "/var/vhosts/connectivitycheck.gstatic.com.access.log"
}

I created the file index.php:

<?php header("HTTP/1.0 204 No Content"); ?>

in /var/vhosts/connectivitycheck.gstatic.com/generate_204

and also the file /var/vhosts/connectivitycheck.gstatic.com.access.log (chmod 666), this to view the results.

I modified /etc/hosts, entering both the IPv4 and IPv6 address (real IPv6 address masked…):

# Chromecast (Don’t) Phone Home
192.168.2.57	connectivitycheck.gstatic.com
2a02:1810:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx	connectivitycheck.gstatic.com

After a lighttpd restart (sudo service lighttpd restart); I was able to browse (from my windows computer) to http://connectivitycheck.gstatic.com/generate_204/, the access log shows the following entry:

1537002921|connectivitycheck.gstatic.com|GET /generate_204/ HTTP/1.1|204|0

so this appears to be working, however:

  • In my firewall, I ensured (NAT rule) all DNS requests (port 53) to 8.8.8.8 and 8.8.4.4 are redirected to my pihole, this to stop devices from using hardcoded google DNS. These rules have been there for a long time and appear to be working fine.
  • With the new lighttpd response active, as soon as I power up the chromecast, I get a message: connected to wifi, but can’t access the internet.
  • I ran a capture on the firewall:
    chromecast IPv4: 192.168.2.131
    pihole IPv4: 192.168.2.57

chromecast tries to get info from 8.8.8.8 (google DNS):

27	10.153746	192.168.2.131	8.8.8.8	DNS	89	Standard query 0xda24 A connectivitycheck.gstatic.com

due to my firewall redirection, the answer comes from my pihole, but the chromecast doesn’t know that:

28	10.154675	8.8.8.8	192.168.2.131	DNS	105	Standard query response 0xda24 A connectivitycheck.gstatic.com A 192.168.2.57

the chromecast now sends a request to 192.168.2.57 (the answer provided by pihole)

29	10.157209	192.168.2.131	192.168.2.57	TCP	74	49128 → 443 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=4294938425 TSecr=0 WS=64

but this request appears to go to port 443 (https), of course pihole, pihole can’t answer https requests, since it doesn’t have the certificate (this is the reason why pihole v4 moved to null blocking - mosts advertisements are served, using https)

The ultimate question(s):

  • something wrong with my lighttpd configuration?
  • in your environment, are the requests to connectivitycheck.gstatic.com also https requests (port 443)?
  • anything I missed or misconfigured?

#5

Wow, thanks a bunch for the great instructions for setting up the vhost on lighttpd. Thanks also for pointing out the necessity of intercepting DNS queries to hard-coded DNS servers, it’s an essential part that I stupidly left out since it’s something I set up ages ago on my firewall and forgot about. It’s an additional requirement that unfortunately puts this solution/hack into another difficulty category. So I do apologise if my incomplete instructions above has sent anyone on a wild goose chase.

Your lighttpd config seems fine, as far as I can see. I haven’t inspected the packets to the degree you have, but the Chromecast continues to work and I don’t see a spike in connection requests. I’ll have a more detailed look using Wireshark when I have some time again.


#6

Hi,

thanks to jpgpi250s most excellent and detailed description, I’ve tried to come up with the appropriate shell commands for this. Could somebody have a look at it, and check if there is something missing?

#  define domain to block
DOMAIN_TO_BLOCK=connectivitycheck.gstatic.com


#  Add vHost skeleton and populate it:
sudo  bash -c 'cat <<"EOF" >>/etc/lighttpd/external.conf
$HTTP["host"] == "DOMAIN_TO_BLOCK" {
    server.document-root = "/var/vhosts/DOMAIN_TO_BLOCK"
    accesslog.filename = "/var/vhosts/DOMAIN_TO_BLOCK.access.log"
}
EOF'
sudo sed -i "s/DOMAIN_TO_BLOCK/${DOMAIN_TO_BLOCK}/" /etc/lighttpd/external.conf


#  Create index.php
mkdir -p /var/vhosts/${DOMAIN_TO_BLOCK}/generate_204
echo "<?php header(\"HTTP/1.0 204 No Content\"); ?>" | sudo tee /var/vhosts/${DOMAIN_TO_BLOCK}/generate_204/index.php


#  Create log file
sudo  touch /var/vhosts/${DOMAIN_TO_BLOCK}.access.log
sudo  chmod 666 /var/vhosts/${DOMAIN_TO_BLOCK}.access.log


#  Modify /etc/hosts
for ip in $(hostname -I); do echo -e "${ip}\t${DOMAIN_TO_BLOCK}" | sudo tee -a /etc/hosts; done


#  Restart lighttpd
sudo  service lighttpd restart

#7

From what I can read (didn’t test) your script will produce the described setup, unfortunately, for me this solution doesn’t work, as indicated earlier.

I’ve been trying to get the original solution to work, but helas…

I think I found the original document here, but the comments in the document describe the problems I’ve been having (newer versions of android - probably also chromecast).

Whireshark indicates the requests are https requests (port 443). lighttpd, out of the pihole box, listens only on port 80. The document indicates you need to have a method to redirect https request to http. The document claims it works, even whithout a valid SSL certificate.

I’ve been trying to get lighttpd to do that (duckduckgo search for “lighttpd redirect https to http”), tried several suggested methods, but failed to get it working.

Anybody???


#8

Try to use multiple ports or even multiple vhosts

Google tries to get out of any hole with not complying to what that port is meant for. It sends DNS, http, etc over port 443.

It is just running past the guards in the firewall and giving the international sign of friendship. :wink:


#9

That’s pretty much what all Google devices do on any network! :smile:
I really hate the Chromecast on my network but hey… the people want YouTube on the big screen! LOL!


#10

DPI would help and if it can’t be decoded that let’s assume it is real traffic. If it is being recognized as an other protocol then it should be stopped.