So, I spent a week migrating all of my wireless devices moved over to a dedicated VLan, it was all going so well. Everything worked except for one thing. It shouldn’t have been a big deal, but I am super particular about these things. I ended up moving all wireless traffic back over to the main LAN.
I was no longer able to screencast my YouTube content from my iPhone to my Samsung televisions. After digging into it - it is because of multicast forwarding - kind of. When the YouTube app starts up, it sends an SSDP discovery packet to find the televisions on the network. I could see the televisions that were connected wirelessly, but none that were plugged into the wired LAN. Well, this sucks - I say to myself.
After a day of packet sniffing on both wireless and wifi (laptop with two nics), I found that it really isn’t a PepLink issue at all. The YouTube app developers put the TTL of the discovery and corresponding responses to the query to 1. The UDP packet - which should be blocked at the WAN gateway (the multicast address is non-routable, but it is supposed to be available to devices on the LAN). Other PNP stuff works fine, so I am sure that the TTL is causing it to die at the subnet boundary.
I have asked the “help me” folks at YouTube why this is set so low and if they could possibly make it configurable in an upcoming update. Fingers crossed. If not, maybe peplink could save the day and implement something similar to the bonjour forwarding feature. Until then, I am working on a SSDP cache service to run on a machine with access to both networks concurrently. I will schedule a discovery probe every 10 minutes on each LAN segment and then “spoof” a response on behalf of the other network segment. Anyone else run into similar problems with VLANS? I imagine that it would be hit and miss since the SSDP standard does not specify the proper TTL.