UDP Broadcast Relay

[stich86]

yes, currently my LAN zone has just a rule with anything open
in the attachment this is my current IoT rule set

[marjohn56]

You need the rule on the IOT LAN from the Sky box. Add a rule on the IOT LAN


Action: Pass
Direction: In
Interface: The IOT LAN/VLAN on which the Sky Q lives
TCP version: 4
Protocol: Any
Source: Single Host or network: Enter the address of your Sky Q box.
Destination: The Net of the LAN where your client app is, in my case it's my primary VLAN so it appears as QPVLAN net from the dropdown box
The rest if the settings are default.
As there is no way of knowing what port(s) the Q box is going to use to talk to the client you have to leave all ports open for it, but only for the Q box itself, hence specifying the source as the Q Box.

[stich86]

it's not working :(
this is a TCPDUMP on the LAN side, I can see the packet with multicast and 1900 port:

19:39:50.925776 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:51.400938 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:51.974473 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:52.409893 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:53.021373 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:54.575089 IP 10.0.2.102.33820 > 239.255.255.250.1900: UDP, length 391
19:39:54.585951 IP 10.0.2.102.33820 > 239.255.255.250.1900: UDP, length 400
19:39:54.586837 IP 10.0.2.102.33820 > 239.255.255.250.1900: UDP, length 443
19:39:54.595408 IP 10.0.2.102.56461 > 239.255.255.250.1900: UDP, length 435
19:39:54.608613 IP 10.0.2.102.35998 > 239.255.255.250.1900: UDP, length 431
19:39:54.611086 IP 10.0.2.102.55354 > 239.255.255.250.1900: UDP, length 431
19:39:54.675932 IP 10.0.2.102.52893 > 239.255.255.250.1900: UDP, length 391
19:39:54.699198 IP 10.0.2.102.52893 > 239.255.255.250.1900: UDP, length 400
19:39:54.700161 IP 10.0.2.102.52893 > 239.255.255.250.1900: UDP, length 443
19:39:54.700186 IP 10.0.2.102.45252 > 239.255.255.250.1900: UDP, length 435
19:39:54.700205 IP 10.0.2.102.44194 > 239.255.255.250.1900: UDP, length 431
19:39:54.700222 IP 10.0.2.102.50255 > 239.255.255.250.1900: UDP, length 431
19:39:54.852066 IP 10.0.2.102.47141 > 239.255.255.250.1900: UDP, length 391
19:39:54.864000 IP 10.0.2.102.47141 > 239.255.255.250.1900: UDP, length 400
19:39:54.865469 IP 10.0.2.102.47141 > 239.255.255.250.1900: UDP, length 441
19:39:54.877949 IP 10.0.2.102.45838 > 239.255.255.250.1900: UDP, length 439
19:39:54.964780 IP 10.0.2.102.35901 > 239.255.255.250.1900: UDP, length 391
19:39:54.970416 IP 10.0.2.102.35901 > 239.255.255.250.1900: UDP, length 400
19:39:54.970432 IP 10.0.2.102.35901 > 239.255.255.250.1900: UDP, length 441
19:39:54.971131 IP 10.0.2.102.42460 > 239.255.255.250.1900: UDP, length 439
19:39:54.978979 IP 10.0.1.100.36914 > 239.255.255.250.1900: UDP, length 101
19:39:57.402953 IP 10.0.2.103.46812 > 239.255.255.250.1900: UDP, length 391
19:39:57.403721 IP 10.0.2.103.50473 > 239.255.255.250.1900: UDP, length 439
19:39:57.403739 IP 10.0.2.103.46812 > 239.255.255.250.1900: UDP, length 400
19:39:57.403749 IP 10.0.2.103.46812 > 239.255.255.250.1900: UDP, length 441
19:39:57.501526 IP 10.0.2.103.45625 > 239.255.255.250.1900: UDP, length 391
19:39:57.502320 IP 10.0.2.103.45625 > 239.255.255.250.1900: UDP, length 400
19:39:57.502338 IP 10.0.2.103.45625 > 239.255.255.250.1900: UDP, length 441
19:39:57.512406 IP 10.0.2.103.59306 > 239.255.255.250.1900: UDP, length 439
19:39:58.609947 IP 10.0.2.101.50033 > 239.255.255.250.1900: UDP, length 391
19:39:58.616509 IP 10.0.2.101.50033 > 239.255.255.250.1900: UDP, length 400
19:39:58.617198 IP 10.0.2.101.50033 > 239.255.255.250.1900: UDP, length 449
19:39:58.623296 IP 10.0.2.101.57373 > 239.255.255.250.1900: UDP, length 431
19:39:58.651478 IP 10.0.2.101.40230 > 239.255.255.250.1900: UDP, length 435
19:39:58.651497 IP 10.0.2.101.41778 > 239.255.255.250.1900: UDP, length 435
19:39:58.651512 IP 10.0.2.101.34482 > 239.255.255.250.1900: UDP, length 453
19:39:58.651526 IP 10.0.2.101.52958 > 239.255.255.250.1900: UDP, length 439
19:39:58.712615 IP 10.0.2.101.52922 > 239.255.255.250.1900: UDP, length 391
19:39:58.713300 IP 10.0.2.101.52922 > 239.255.255.250.1900: UDP, length 400
19:39:58.725730 IP 10.0.2.101.52922 > 239.255.255.250.1900: UDP, length 449
19:39:58.736272 IP 10.0.2.101.51055 > 239.255.255.250.1900: UDP, length 435
19:39:58.736290 IP 10.0.2.101.53165 > 239.255.255.250.1900: UDP, length 453
19:39:58.736307 IP 10.0.2.101.38655 > 239.255.255.250.1900: UDP, length 431
19:39:58.736349 IP 10.0.2.101.46696 > 239.255.255.250.1900: UDP, length 435
19:39:58.736371 IP 10.0.2.101.55974 > 239.255.255.250.1900: UDP, length 439
19:39:59.671583 IP 10.0.2.103.55595 > 239.255.255.250.1900: UDP, length 391
19:39:59.680952 IP 10.0.2.103.55595 > 239.255.255.250.1900: UDP, length 400
19:39:59.687785 IP 10.0.2.103.55595 > 239.255.255.250.1900: UDP, length 443
19:39:59.687811 IP 10.0.2.103.53717 > 239.255.255.250.1900: UDP, length 435
19:39:59.698524 IP 10.0.2.103.36531 > 239.255.255.250.1900: UDP, length 431
19:39:59.698542 IP 10.0.2.103.33524 > 239.255.255.250.1900: UDP, length 431
19:39:59.776345 IP 10.0.2.103.45391 > 239.255.255.250.1900: UDP, length 391
19:39:59.777213 IP 10.0.2.103.45391 > 239.255.255.250.1900: UDP, length 400
19:39:59.777242 IP 10.0.2.103.45391 > 239.255.255.250.1900: UDP, length 443
19:39:59.780551 IP 10.0.2.103.51321 > 239.255.255.250.1900: UDP, length 435
19:39:59.796703 IP 10.0.2.103.42519 > 239.255.255.250.1900: UDP, length 431
19:39:59.797466 IP 10.0.2.103.36201 > 239.255.255.250.1900: UDP, length 431

10.0.1.122 is my iPhone where SkyGo is running
10.0.2.101 is Sky Q Platinum
10.0.2.102-103 are the two Sky Minis

I don't see any other traffic than the SSDP, it looks like the app cannot really find where is the Platinum

[marjohn56]

It definitely works, many of us are using it right now. So let's see what settings you have. It should look like below...





and the firewall rule.

[stich86]

It definitely works, many of us are using it right now. So let's see what settings you have. It should look like below...





and the firewall rule.

Hi,

i've the same rules.
Just a question: Are your Sky Q boxes replies to ping?
Mine not, but i'm in Italy and we don't have the same firmware..

Looks like that after some time, the OPNSense lost ARP entries and the box reply only if the traffic start from it

Thanks

[marjohn56]

Sky Q's definitely do not reply to pings.

[stich86]

ok, so also other firmware have the same behaviour

i'll try to find why this damn app cannot find the Q :(

[marjohn56]

If you can, run wireshark on the IOT VLAN/LAN, you should see the multicast packets coming from the LAN, the source address should be the client app. You should also see the packets then coming from the Q itself, they will not be multicast but will have the source address of the Q and the destination should be the client app. If you see all that and the app is not getting those packets then there is a firewall issue.

[stich86]

the problem is that i'm seeing multicast packet on both interface, but anything else.
Looks like that the client doesn't know where is the SkyQ, so it doesn't start the TCP communication

[marjohn56]

You will see multicast on both, that's the idea, when the Q sees that packet it responds unicast back to the client.

[stich86]

ok.. may be i've found the problem.

The Multicast traffic is passed over ethernet, but when reach the AP (Unifi AC HD), the packet is not broadcasted over WLAN

I think this is related to the block broadcast on IoT WLAN that i've put in place for a problem with Shelly devices.

Now i'll try to see if I can put an exception..

[stich86]

ok fixed!
i've put a rule to allow OPNSense and my iPhone to multicast on IoT SSID, and now I can reach my Sky Q Platium :D

Thanks for the hits :)

[marjohn56]

Told you it worked.  :)

[thexy]

Great piece of software, has helped me getting a multi-function device discovered across VLANs. I have a situation with a smart TV now that I can't quite solve. Maybe you can point me in the right direction.

I have a 2017 Samsung TV so it implements the Google Cast/Chromecast built-in predecessor Discovery and Launch (DIAL), specs for reference. Essentially DIAL clients such as the Youtube app on a smartphone use Simple Service Discovery Protocol to 239.255.255.250 on UDP port 1900.

From udpbroadcastrelay's side I'm using:

Code Select Expand

udpbroadcastrelay --id 4 --port 1900 --dev igb0_vlan1060 --dev igb0_vlan1042 -s 1.1.1.1 --multicast 239.255.255.250 -d

Matching rules are in place:

Code Select Expand

# DIAL clients net (smartphones and their Youtube apps live here)
pass in quick on igb0_vlan1060 inet proto udp from {(igb0_vlan1060:network)} to {239.255.255.250} port {1900} keep state

# Entertainment net (TV implementing a DIAL server lives here)
pass in log quick on igb0_vlan1042 inet proto udp from {(igb0_vlan1042:network)} to {10.10.42.1} port {1900} keep state

Now when a DIAL client sends SSDP requests, here's the output of udpbroadcastrelay that I'm a bit confused by. In this example the client's at 10.10.60.100, the DIAL server at 10.10.42.16.

Code Select Expand

ID set to 4
Port set to 1900
Outgoing source IP set to 1.1.1.1
ID: 4 (DSCP: 4, ToS: 0x10), Port 1900
igb0_vlan1060: 12 / 10.10.60.1 / 10.10.60.255
igb0_vlan1042: 19 / 10.10.42.1 / 10.10.42.255
found 2 interfaces total
IP_ADD_MEMBERSHIP:              10.10.60.1 239.255.255.250
IP_ADD_MEMBERSHIP:              10.10.42.1 239.255.255.250
Done Initializing

<- [ 10.10.60.100:40536 -> 239.255.255.250:1900 (iface=12 len=125 tos=0x00 DSCP=0 ttl=1)
-> [ 10.10.42.1:1900 -> 239.255.255.250:1900 (iface=19 len=125 tos=0x10 DSCP=4 ttl=1)

<- [ 10.10.42.16:41954 -> 10.10.42.1:1900 (iface=19 len=411 tos=0x00 DSCP=0 ttl=64)
-> [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)

<- [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=5 len=411 tos=0x10 DSCP=4 ttl=64)
IP DSCP (4) matches ID. IP ToS 0x10. Packet Ignored.

I'd expect the replicated response back in DIAL clients' net to go something like:

Code Select Expand

-> [ 10.10.60.1:1900 -> 239.255.255.250:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)

Instead the replicated response looks like

Code Select Expand

-> [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)

DIAL server at .42.16 gets the request and sends its response, tcpdump confirms it's got what looks like proper content.

Code Select Expand

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
    CACHE-CONTROL: max-age=1800\r\n
    DATE: Sun, 04 Apr 2021 02:58:36 GMT\r\n
    EXT: \r\n
    LOCATION: http://10.10.42.16:7678/nservice/\r\n
    SERVER: Samsung-Linux/4.1, UPnP/1.0, Samsung_UPnP_SDK/1.0\r\n
    ST: urn:dial-multiscreen-org:service:dial:1\r\n
    USN: uuid:7bbede11-cb5a-4c60-b356-ab6914661a7f::urn:dial-multiscreen-org:service:dial:1\r\n
    WAKEUP: MAC=9c:8c:6e:00:00:02;Timeout=10\r\n
    Content-Length: 0\r\n
    BOOTID.UPNP.ORG: 9\r\n
    \r\n
    [HTTP response 1/1]

In DIAL clients net that response is never seen. Am I missing something obvious why the reply packet apparently doesn't get replicated back into the DIAL client's net?

//edit: Similar to Chromecast in later versions I only get a response at all by using source address 1.1.1.1. I also tried '--ttl-id' for fun, it increased the TTL header as outlined in the manual, behavior itself was the same.

[marjohn56]

The reply packet is not 239.255.255.250, try adding a specific rule to allow the reply packets to get back to the LAN where the client is.