| ▲ | jwr 2 hours ago | ||||||||||||||||
Incidentally, this client isolation thing can be extremely annoying in practice in networks you do not control. Hardware device makers just assume that everything is on One Big Wi-Fi Network and all devices can talk to all other devices and sing Kum-Ba-Yah by the fire. Then comes network isolation and you can no longer turn on your Elgato Wi-Fi controlled light, talk to your Bose speaker, or use a Chromecast. | |||||||||||||||||
| ▲ | gh02t an hour ago | parent | next [-] | ||||||||||||||||
I mean, yeah, isn't that the main purpose of client isolation? It sucks when you're on something like a locked down university dormitory network but it also stops (or at least, inhibits) other people from randomly turning on your lightbulb or worse, deploying exploits on your poorly engineered IoT device and lighting you up with malware. | |||||||||||||||||
| ▲ | wtallis 2 hours ago | parent | prev | next [-] | ||||||||||||||||
Even when not using client isolation, I've run into similar problems simply from having a computer connected over Ethernet instead of WiFi, and whatever broadcast method a gadget uses for discovery didn't get bridged between wired and wireless. (Side note: broadcast traffic on WiFi can be disproportionately problematic because it needs to be transmitted at a lowest common denominator speed to ensure all clients can receive it. IIRC, that usually means 6Mbps.) | |||||||||||||||||
| ▲ | Chihuahua0633 2 hours ago | parent | prev [-] | ||||||||||||||||
Adding exceptions for certain protocols, IP ranges (maybe multicast, even) are certainly ways around this, but I imagine with every hole you poke to allow something, you are also opening a hole for data to leak. | |||||||||||||||||
| |||||||||||||||||