Connecting Alexa & Smart TV on a Guest Wifi

[JohnUK]

We have over 80 sites in the UK with Meraki WIFI.  These sites have Guest WIFI and some residents in the rooms want to connect their Alexa to Smart TV etc.  The guest WifI is on a Meraki DHCP.

Has anybody have any idea how this can be achieved?

[MerakiDave]

So it sounds like you're using NAT mode SSIDs in which case the clients get a seemingly random 10.0.0.0/8 address and are L2 isolated automatically and the AP handles the NAT and DHCP, so that's all good for a Guest SSID.  I would expect something like an Alexa setup to be routine, power it up, connect locally via the Alexa app and input the wifi info so it can connect out to Amazon.  Same for any general Smart TV, whatever the normal network setup is using the TV menus to select the Guest SSID and get connected.  Then I'd expect it's just a matter of enabling the right Alexa skill to control the TV.  Sorry if I misunderstood the question, all that was already done and things are not working?  And if so, bounce it off Meraki Support to take a look at your SSID config?

[BrechtSchamp]

Actually it's possible that Alexa needs to be able to communicate directly with the smart TV via the local subnet rather than the internet. So the L2 isolation would be a problem in that case.

Unfortunately you can't use NAT mode without the isolation. So in that case you'd need to switch to bridge mode. This way the existing DHCP server on the LAN network would need to hand out IP addresses to the client (a Meraki MX or a provider modem for example).

The clients would be able to communicate directly on the subnet. Note that this is generally not desired in guest networks. Let's say for example that your 80 sites are holiday houses and are rented out as a whole to families. Then this is less of an issue. But if multiple families/unrelated people use the same SSID at the same time this might not be desirable.

[MerakiDave]

Agreed @BrechtSchamp if that's the case, if they need L2 communication to be in the same broadcast domain then NAT mode would prevent that direct communication.  And I don't believe it can be toggled off.  That is, client isolation can be toggled on with a bridge mode SSID, but cannot be toggled off with a NAT mode SSID.  Thought it may not matter on the Alexa side but perhaps it's the TV that might require L2 adjacency to receive commands from Alexa over the local LAN? 

[Uberseehandel]

@MerakiDave @BrechtSchamp 

I have my Chromecast capable devices on their own VLAN.

A smartphone, needs to be on the same VLAN to control the Chromecast device. However, once the device has started casting, the phone can detach from the VLAN.

At some stage I shall experiment with Bluetooth, although, at present, the IoT WiFi is not Bluetooth aware, but technically the Chromecast devices can use Bluetooth. There are security reasons for being very careful with Bluetooth.

In this environment, the video devices, including Smart TVs, do not stream videos as directed by another device(phone), but rather connect to the internet source directly, at the margin, this allows greater throughput and smoother playback.

Devices which need to access screens, STBs, playout systems etc, use HDMI to connect, not Ethernet.

[Nick]

That does sound like its going to require an overhaul if Alexa requires the ability to contact the devices.

Which by the sounds of it won't be a small job!

[Uberseehandel]

---

@Nick wrote:
That does sound like its going to require an overhaul if Alexa requires the ability to contact the devices.

Which by the sounds of it won't be a small job!

---

If a Chromecast compatible IGMP proxy/reflector were to be implemented on the MX range, then there is every probability that a device on a VLAN other than that which the Chromecast devices use could connect to the desired Chromecast/Alexa device.

It is worth experimenting with enabling the Bonjour gateway

For me, it was more cost effective to use another brand of switch and security appliance to allow the network to be split into two parts - one for the known secure devices, and one for everything else.