ā05-16-2018 12:08 AM
I'm looking at blocking inter-station traffic, by unticking 'Enable Inter-Station Traffic' but I'm also looking at using Apple TVs and Chromecasts on the WiFi. Just wondering if anyone has come up with a way to still allow access to services like Apple TVs or Chromecasts without the need to cable them in?
Solved! Go to Solution.
ā05-17-2018 06:30 PM
That depends a lot on the version of the AppleTVs. The 3rd generation and newer (I think) actually use low power bluetooth for pairing to the iOS device to do the screen share. Meaning they don't even have to be connected to a WLAN to work.
The older ones use the WLAN for all communications.
https://help.apple.com/deployment/ios/#/apd8fc751f59
Bonjour would be needed to traverse VLANs, not SSIDs specifically (unless the SSIDs were attached to different VLANs).
ā11-03-2022 06:46 AM
Maybe im missing something, but disabling inter-station traffic doesnt stop anyone connecting to an Apple TV. I disabled that setting which helped speed up our wifi network tremendously.
As for the Apple TV's, and Bonjour, as long as you configure Bonjour within the XIQ properly, you wont have any issues. I have dozens of Vlans, with the Apple TV's on one Vlan, faculty on another, and students on yet another Vlan, and all can stream to the Apple TV, can print to Bonjour enabled printers. no problem at all. Enabling Bonjour, you will see it inject itself into your DHCP server and in each of the Vlans...
So, i dont get why anyone is saying disabling that setting would stop a Macbook from connecting to an Apple TV..... of course Bonjour is the WORST protocol EVER, and should be at end of life (years ago)..... i remember apple looking at "Wide Area Bonjour" and worked on it until it fell apart and they realized it wasnt worth it to them... and i believe work stopped back in 2009....... I just wish they should scrap bonjour and use any other protocol out there for their **** devices..... anyway, the above is my experience on disabling that setting.
Jason.
ā05-21-2018 06:52 AM
@Brian Powersā I've done some more testing today, I think I must have only tested scenario 2.
The following is how I had it setup:
Scenario 1:
Clients on SSID 2 couldn't communicate with each other but can communicate with clients on SSID 1.
Scenario 2:
Clients on SSID 2 can't communicate with each other and SSID 1, and SSID 1 can't communicate with each other and SSID 2.
I also tried the above with Firewall rules but they didn't seem to have an effect on the mDNS traffic either way.
Sorry for any confusion!
ā05-18-2018 01:24 PM
@Carsten Buchenauā It sounds like it may not anymore. Seems as if @Hammertimeā is seeing differing results now. I've not testing it in quite some time, so a version of HiveOS could have altered the behavior.
ā05-18-2018 05:11 AM
@Brian Powersā Good point, I didn't realize this setup would work ļ Which is, actually, another argument that "1 SSID" is not always the best implementation. We changed a large school from 4 (students, faculty, private devices + guests) to 1 SSID using PPSK, and we see 3 main issues now:
As mentioned in my first answer, Aerohive confirmed that they are working on a better way to handle Multicast traffic, which might solve most of these issues, we will see.
Until then we are discussing with the school to go back to 2 or even 3 SSIDs...