UDP Broadcast Relay

[mightyi]

Sky Q is why I originally put this package together. 😊

I suspect you need to add a firewall entry on your PC. Windows will block the responses from the Q box as it's coming from an address on a different VLAN.

Open windows firewall, Select Advanced Settings

Select Inbound Rules
New Rule

Name: Sky Q Pass
Enabled: Ticked

Protocol and Ports Tab
Proto Type: Any

Ports: Local and Remote: Any

Scope Tab
Local IP address: Any
Remote IP: YOUR Q BOX IP - In my case 10.4.15.91

Advanced Tab:
Specify profiles to which this rule apples
Tick all of them

That should do you.

Sir you are indeed correct - Thank You!  As a chance, i looked at the eset firewall on my pc, and it was blocking SSDP traffic and traffic from the SkyGo executable.  unblocking this immediately fixed the issue with Sky Q connecting on my PC.  I've now added the streaming and IoT Subnets to trusted zones on the basis that if i've allowed the traffic through the firewall, then it's safe!

Of course I'm now left with other issues, but that's another thread..... :)

[WireGuardStrim]

Has anyone been able to get this plugin working with wireguard? It fails to start whenever I try with a wireguard interface.

Thanks!

[Patrick M. Hausen]

A broadcast relay cannot work over point to point interfaces. Only for broadcast interfaces, i.e. Ethernet, nowadays.

[meschmesch]

I've been out of luck to use this amazing UDP Broadcast Relay for WS-Discovery across VLANS...

It works well for mDNS with my chromecasts

But for WS-Discovery, no matter what source IP I use, "empty", "1.1.1.1" or "1.1.1.2" it just does not manage to let WS-Discovery work from one vlan/subnet to another.

In fact, with "empty", it almost works : probe requests reached the other subnet, that answsers with a probe-match. But Windows has the good idea to see the probe-match packet, but since the source IP is outside it's subnet, it doesn't try to resolve it...

I would like/need this UDP to act like a proxy for WS-discovery, and replace do something similar to NAT, which I thought could be the 1.1.1.1 or 1.1.1.2 source, but in fact sadly no...

Would you be willing to look at the ws-discovery protocol and implement some other mechanism to be able to act as a ws-discovery proxy (lots of documentation show this is allowed by the protocol but I could find no implementation of this anywhere).

Thanks in advance for your reading.

Hello, is there any solution to this issue? I confirm that with UDP Broadcast relay on Port 3702 and Broadcast Address 239.255.255.250 Windows does receive the packets, but for whathever reasons they are disregarded - indeed probably they originate from the wrong subnet...

Thanks!