How can I get this UDP relay package for casting across VLANs?

[Itar]

Hi tman222,

thank you very much!

I read your post, but I thought it would also work with "/usr/local/sbin" instead of "/root/udpbroadcastrelay/". Now I copied "udpbroadcastrelay" to root... and it works like a charm

[tman222]

@itar said in How can I get this UDP relay package for casting across VLANs?:

Hi tman222,

thank you very much!

I read your post, but I thought it would also work with "/usr/local/sbin" instead of "/root/udpbroadcastrelay/". Now I copied "udpbroadcastrelay" to root... and it works like a charm

Hi @Itar - I would have expected it to work from /usr/local/sbin as well as long as you have the /usr/local/nohup and call the executable by ./udpbroadcastrelay if needed (note the ./) The instructions above are bit dated back from when we had to compile the code manually to create the binary vs. installing it as a FreeBSD package.

[Itar]

Hi tman222,

no, I tried /usr/bin/nohup /usr/local/sbin/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb0 --dev igb1 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null but it didn't work.

[Itar]

This post is deleted!

[tman222]

@itar said in How can I get this UDP relay package for casting across VLANs?:

Hi tman222,

no, I tried /usr/bin/nohup /usr/local/sbin/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb0 --dev igb1 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null but it didn't work.

Hmmm - do either of these work?

/usr/bin/nohup /usr/local/sbin/./udpbroadcastrelay --id 1 --port 5353 --dev igb0 --dev igb1 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null

or

/usr/bin/nohup /usr/local/sbin/udpbroadcastrelay --id 1 --port 5353 --dev igb0 --dev igb1 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null

[Itar]

Ahhhhh,

/usr/bin/nohup /usr/local/sbin/udpbroadcastrelay --id 1 --port 5353 --dev igb0 --dev igb1 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null

is working!

Thanks!

[CaptainCathode]

Re: How can I get this UDP relay package for casting across VLANs?

So I just came across this thread after trying for over a day to get Sonos clients on my LAN subnet discovering the Sonos devices on an isolated IOT subnet using the PIMD package as a multicast reflector.

IOS clients that had previously been connected when everything was on the same subnet continue to work once the relevant firewall rules were setup, but new clients (Mac, Win10) can't discover the Sonos device.

I've removed PIMD, rebooted and installed the package as per the instructions above. I'm seeing the following error when trying to run the command (as root) with the debug option:

# udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -d
ID set to 1
Port set to 1900
ID: 1 (DSCP: 1, ToS: 0x04), Port 1900
igb1: 2 / 172.16.10.1 / 172.16.10.255
igb2: 3 / 172.16.20.1 / 172.16.20.255
found 2 interfaces total
IP_ADD_MEMBERSHIP:		172.16.10.1 239.255.255.250
IP_ADD_MEMBERSHIP:		172.16.20.1 239.255.255.250
bind: Address already in use
rcv bind

Not sure what would already be using 239.255.255.250:1900 or how to go about debugging from here.

Any pointers greatly appreciated

[Qinn]

did you do a ps to check if it is already running?

[CaptainCathode]

There are no other instances of udpbroadcastrelay running but pfTop shows an existing state from the pfsense interface on the IOT subnet.

pfTop: Up State 1-1/1 (545), View: default, Order: bytes
PR        DIR SRC                           DEST                                   STATE                AGE       EXP     PKTS    BYTES
udp       Out 172.16.20.1:52980             239.255.255.250:1900               SINGLE:NO_TRAFFIC   00:02:52  00:00:09      132    62676

I'll try temporarily powering down all other devices on that subnet and see if that helps

[Qinn]

The way to check if it running and to stop udpbroadcastrelay is using the ps command and kill the process using it's process number (PID)

[2.5.0-RELEASE][root@pfSense.localdomain]/root: ps
  PID TT  STAT     TIME COMMAND
 7615 u0- S    41:14.27 /usr/local/sbin/pcscd
60580 u0  Is    0:00.02 login [pam] (login)
60845 u0  I     0:00.01 -sh (sh)
61388 u0  I+    0:00.01 /bin/sh /etc/rc.initial
 2456 v0  I     0:00.02 -sh (sh)
 3896 v0  I+    0:00.01 /bin/sh /etc/rc.initial
99884 v0  Is    0:00.02 login [pam] (login)
  188 v1  Is+   0:00.01 /usr/libexec/getty Pc ttyv1
  330 v2  Is+   0:00.01 /usr/libexec/getty Pc ttyv2
  368 v3  Is+   0:00.01 /usr/libexec/getty Pc ttyv3
  579 v4  Is+   0:00.01 /usr/libexec/getty Pc ttyv4
  592 v5  Is+   0:00.01 /usr/libexec/getty Pc ttyv5
 1002 v6  Is+   0:00.01 /usr/libexec/getty Pc ttyv6
 1293 v7  Is+   0:00.01 /usr/libexec/getty Pc ttyv7
 6730  0  S     0:00.00 udpbroadcastrelay --id 1 --port 1900 --dev igb1.1005 --dev igb1.1007 --multicast 239.255.255.250 -f
 6919  0  R+    0:00.01 ps
41171  0  Is    0:00.02 -sh (sh)
41565  0  I     0:00.01 /bin/sh /etc/rc.initial
45295  0  S     0:00.12 /bin/tcsh

/root: kill 6730

[2.5.0-RELEASE][root@pfSense.localdomain]/root: ps
  PID TT  STAT     TIME COMMAND
 7615 u0- S    41:14.29 /usr/local/sbin/pcscd
60580 u0  Is    0:00.02 login [pam] (login)
60845 u0  I     0:00.01 -sh (sh)
61388 u0  I+    0:00.01 /bin/sh /etc/rc.initial
 2456 v0  I     0:00.02 -sh (sh)
 3896 v0  I+    0:00.01 /bin/sh /etc/rc.initial
99884 v0  Is    0:00.02 login [pam] (login)
  188 v1  Is+   0:00.01 /usr/libexec/getty Pc ttyv1
  330 v2  Is+   0:00.01 /usr/libexec/getty Pc ttyv2
  368 v3  Is+   0:00.01 /usr/libexec/getty Pc ttyv3
  579 v4  Is+   0:00.01 /usr/libexec/getty Pc ttyv4
  592 v5  Is+   0:00.01 /usr/libexec/getty Pc ttyv5
 1002 v6  Is+   0:00.01 /usr/libexec/getty Pc ttyv6
 1293 v7  Is+   0:00.01 /usr/libexec/getty Pc ttyv7
37961  0  R+    0:00.00 ps
41171  0  Is    0:00.02 -sh (sh)
41565  0  I     0:00.01 /bin/sh /etc/rc.initial
45295  0  S     0:00.13 /bin/tcsh

[sinbox_pfs]

@captaincathode Would be good to disable other related plugins and/or other firewall rules on you IoT subnet like Avahi etc if you ever had them installled.

[sinbox_pfs]

Anyone here using HomeKit across VLAN’s? I have Apple’s Home app successfully work to recognise and control many devices on my IoT VLAN’s.

One minor annoyance I have been having is with a particular smart home device - Meross Garage opener (HomeKit version). Their mobile app works fine over VLAN’s, however via the native Apple Home app(& via Siri) I’m unable to open the garage on the first request (even though the app acknowledges that the request has been successfully completed). The subsequent call / 2nd request always works like a charm and the garage opens up consistently. This means my garage door automations don’t work as expected via the Shortcuts or Home App.

I’m wondering if that’s due to the nature of VLAN hops and how that specific device works across VLAN’s? Or some other issue related to HomeKit or the Home App on iOS itself? FWIW, I have plenty of other IoT devices(eg Light Bulbs, Sonos speakers etc) connected via HomeBridge all of which work fine (mostly :-)) on the first attempt.

[CaptainCathode]

Getting back to this after nearly two weeks of being too busy to look at it . . .

I found that UPnP/NAT-PMP was preventing udpbroadcastrelay from starting. I have an XBox One on the same IOT subnet, and pfSense is configured to allow it to use UPnP.

If I stop the UpNP/NAT-PMP daemon (miniupnpd) I can successfully start udpbroadcastrelay and my Sonos controller can now see the devices across subnets.

udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -d

Of course then I can't start miniupnpd again until the udpbroadcastrelay process is killed, so it seems the two are mutually exclusive, or at least when both are trying to use UDP 1900 (SSDP) on multicast address (239.255.255.250).

Other than moving the XBox or Sonos devices into their own VLAN, I can't see a workable solution here, but admittedly my IPv4 multicast knowledge is pretty basic.

Any further suggestions welcomed.

[stephenw10]

Yes, you can't have two processes listening on the same port like that. You can either relay the SSDP packets or accept and use them with UPnP. Or be more secure and do neither.

Steve

[spaceboy]

Took a look at this as i was hoping it could help me overcome what PIMD seemingly could not, that is the initial discovery of SONOS devices on other VLANS. My set up was working fine once the controller had been connected to the SONOS VLAN and cached the ip addresses.

Unfortunately it does not. Followed what seems to be the fairly straightforward step by step guide by Qinn in post 55 and everything seems to work but nothing is discovered when i restart the pfsense.

Shellcmd per below
🔒 Log in to view

is there any way i can check it is properly running? other than SONOS detection working :)

[CaptainCathode]

@spaceboy - a few suggestions based on my trial and error experiences.

SSH to the console and check if the process is running:

[2.5.1-RELEASE][user@pf.internal.xxx.net]/home/user sudo ps | grep udpbroadcastrelay
13600 u0- S    0:02.44 /usr/local/sbin/udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -f

Check the path to the udbbroadcastrelay executable:

find / -name updbroadcastrelay

My working shellcmd entry is:

/usr/bin/nohup /usr/local/sbin/udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -f > /dev/null

Run pfTop From the diagnostics menu and filter on port 1900. You should be able to see your Sonos devices periodically connecting:
🔒 Log in to view

Also check that you don't have anything else on pfSense running a process bound to UDP/1900 on the same subnet/vlan. I initially had UPnP/NAT-PMP running for the XBox that's on the same subnet as my Sonos devices. That stopped udpbroadcastrelay from working so I made an executive decision that my kids could live without being able to host games and disabled UPnP for the Xbox

Hope that helps

[spaceboy]

@captaincathode thanks for the pointers, i think it helped a bit. linux doesnt really like me much so took me a little while to work through this.

i think its running on the pfsense now. in the console i see 🔒 Log in to view

for me executing that command to check the path to the udbbroadcastrelay executable returns nothing but i don't know if this is some result of me ssh'ing via admin or what? i also noticed the sudo command wasnt needed on the previous and i understand just enough to know thats related to the admin account.

I moved the executable from /root to /usr/local/sbin to match yours but i kept it in a subfolder so my shellcmd is
🔒 Log in to view

and in pftop i see🔒 Log in to view
which seems to me to be good.

but the result is still the same. nothing found by controllers on either windows, android or ios. so i guess whatever the problem is it was probably the same for pimd and that was working too.

my uneducated thought process says there must be something else on the network blocking the broadcast. i have a few switches and a unifi controller running the wireless AP's. is it possible any one of these could be blocking the multicast?

[A Former User]

@spaceboy you’re saying you have Unifi deployed. Do you by chance have the “Auto Optimize” function or “Block LAN to WLAN multicast and broadcast” enabled? These might be the culprit.

Otherwise, you might want to look into:

• Whether your interfaces (vlans) match in the shellcmd command
• Firewall rules that block communication

[spaceboy]

@mg85 thanks, i do have Auto Optimize enabled but not the second.

Also i previously had this working under PIMD once the SONOS controller cached the SONOS devices ip addresses so i don't think its firewall rules.

To be honest i have given up on this for now. I believe i did try with my Sonos One wired into one of the switches to try and determine whether unifi was to blame and i don't think it worked. So i feel it may be more than unifi.

I'm also questioning whether IOT stuff and Sonos devices need seperate VLANs anyway. it was a nice little project but i'm not certain its worth the effort given the large number of ports i have seen people posting about need to have open even once multicast is working. Actually on that point, i'd be interested in understanding people's driver for segregating SONOS devices like this.

Hope to give this another try at some point. Ta

[bitrot]

This was an immensely helpful thread for me. Yet I had problems still with discovery. It turns out that I needed to do additional work because I have Captive Portal setup on my IoT VLAN
I resolved that issue here: https://forum.netgate.com/topic/164733/captive-portal-causing-sendto-permission-denied-errors-with-udpbroadcastrelay
Leaving a reference to it here. Maybe it'll help someone else.