Setting up chromecast across different VLANS/networks ($1877352) · Snippets

Hi - Thank you for the great writeup. I am trying to do the same thing but with a different router. I am installing this on a RPi running Raspbian. I am close, but cannot get it to work.

Question - in step 6 you list the file name to modify as /etc/network/interface. On the Pi I think it is /etc/network/interfaces. Can you conform? I have also seen some avahi writeups that show a new file being created in /etc/network/interfaces.d/vlan. Then you copy a configuration as you have into that file. Is there a difference?

At this point I have followed all the steps and have avahi running and the RPi is showing 4 IP address from the hostname -I command. Here is the content of my /etc/network/interfaces file :

source-directory /etc/network/interfaces.d

auto eth0
iface eth0 inet dhcp

auto eth0.10
iface eth0.10 inet dhcp

auto eth0.15
iface eth0.15 inet dhcp

auto eth0.20
iface eth0.20 inet dhcp

The Pi sits on a "server" network(untagged) and VLAN 10,15, and 20 are the ones I need for be reflected. Note the chromecast is staic on VLAN 10. 15 and 20 are guest and kid networks. I have created the firewall rules necessary to give those vlans access to the chrome cast. I even gave them access to the Avahi RPi server. Ping works between all the subnets.

Any ideas?

Correct, that was a typo, should be: /etc/network/interfaces I will correct that.

Yes, any file in /etc/network/interfaces.d/ will be used as well, you can name it what you want. Just a way to organize multiple network files

What is the output of ip -a on the pi?

Is the port that the Pi is plugged into "Untagged", and all the other vlan ports "tagged"

Hi Carver - thanks for reply. I originally had the pi (avahi server) on a mngt network and the chromecast on different subnet V10. I moved it onto the same subnet as the chromecast and then it started working... So at that point V10 was untagged and my v15 and v25 were. So the Pi picked up dhcp no issues. That is the output you see below.

To be clear, the RPi Avahi server does not need to be on the same subnet/vlan as the Chromecast correct?

Is the port that the Pi is plugged into "Untagged", and all the other vlan ports "tagged" - yes sir.

It must be "ip a" on a Raspbian ?

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:68:e6:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.142/24 brd 192.168.10.255 scope global dynamic eth0
       valid_lft 255319sec preferred_lft 255319sec
    inet6 fe80::dea6:32ff:fe68:e6a1/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether dc:a6:32:68:e6:a2 brd ff:ff:ff:ff:ff:ff
4: eth0.15@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether dc:a6:32:68:e6:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.177/24 brd 192.168.15.255 scope global dynamic eth0.15
       valid_lft 255320sec preferred_lft 255320sec
    inet6 fe80::dea6:32ff:fe68:e6a1/64 scope link
       valid_lft forever preferred_lft forever
5: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether dc:a6:32:68:e6:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.106/24 brd 192.168.20.255 scope global dynamic eth0.20
       valid_lft 6920sec preferred_lft 6920sec
    inet6 fe80::dea6:32ff:fe68:e6a1/64 scope link
       valid_lft forever preferred_lft forever

I think that all looks good. My use case was to put his the chomecast on a "main" and allow 2 other (kid) and (guest) network access to it. I also like the idea of using an IoT network.

Either way - I will try again by putting the pi avahi serer back in a management network and try again. I then may move the chromecast to the IOT.

So - auto eth0 / inface eth0 inet dhcp pickups ip an address from the untagged network? Since it was set to DCHP for the untagged network again feels a little strange. Is this more to simply inform Avahi?

Thanks again for doing this. I have tried to figure it out for a long time..... I will try again and report back.

I just wanted to report back - I went back at this and got it working. I had some firewall zone issues to deal with. Thanks for the great write up!

If I understand this writeup correctly, it will replicate everything the avahi daemon sees.

Exactly which service type will replicate chromecast?

This is useful in an environment where you don't intend to replicate everything from one network to another.