"EnTerr" wrote:
"RokuKC" wrote:
By the way, I'm fairly sure it doesn't matter for Roku, but I believe technically you should include a MX: timeout line in the M-SEARCH query, e.g. MX: 3.
Yup. True on both: UPnP spec requires MX header but Roku player does not care (i just checked behavior is unchanged). Best to be compliant and send "MX: 1" though.
@LCubed - who are you sending the datagram to? Should be to 239.255.255.250. And are you listening for unicast response (i.e. direct reply)?
Yes, I'm sending the datagram to 239.255.255.250. I'm not really even listening yet. I wanted to check the response with Wireshark first to verify what I should see. I have Wireshark setup to look for traffic on port 1900, and the display filter set to (ip.src == 192.168.10.127) || (ip.src == 192.168.10.242)
.127 is the Roku, and .242 is the AMX control system sending out the multicast datagram.
So additional info:
The Roku is connected via WiFi to a Layer 2 managed switch connected to another Layer 2 managed switch which has the control system AND my laptop connected to it. One thing I could try is connecting my laptop to WiFi (like the Roku) and then seeing if I can still see the multicast datagram going out of the control system via Wireshark on the laptop. I'll try that once I'm back from my business trip (6/19).