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

tman222

@stephenw10 - when installing the udpbroadcastrelay as a FreeBSD package, where on the file system is the binary located (will be needed for ShellCmd)? Thanks in advance.

bmeeks

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

@stephenw10 - when installing the udpbroadcastrelay as a FreeBSD package, where on the file system is the binary located (will be needed for ShellCmd)? Thanks in advance.

Usually binary executables from packages go in /usr/local/bin and configuration files in /usr/local/etc. Any shell script provided with the package typically winds up in /usr/local/etc/rc.d. But these are not hard and fast rules - a package creator might deviate from the standard practice.

Qinn

@tman222 Do a

find / -name 'udpbroadcastrelay'

and you will find it's location.

Qinn

btw if you don't have the repository, then do a

 pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/udpbroadcastrelay-0.3.b.txz

for an AMD64 and then a

rehash

and a

 pkg info udpbroadcastrelay

shows it is nicely installed

[2.5.0-RELEASE][root@pfSense.localdomain]/: pkg info udpbroadcastrelay
udpbroadcastrelay-0.3.b
Name           : udpbroadcastrelay
Version        : 0.3.b
Installed on   : Wed Mar 17 11:54:50 2021 CET
Origin         : net/udpbroadcastrelay
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : net
Licenses       : GPLv2
Maintainer     : m.muenz@gmail.com
WWW            : https://github.com/marjohn56/udpbroadcastrelay
Comment        : UDP multicast/unicast relayer
Annotations    :
        FreeBSD_version: 1202000
Flat size      : 39.2KiB
Description    :
udpbroadcastrelay is a UDP multicast relayer. Its intended use is to
rebroadbcast udp packets on a specific port across interfaces, be those
interfaces physical or VLAN.

It is used where devices such as Sonos or Sky are spread accross
different subnets and are not able to detect the servers or devices.

WWW: https://github.com/marjohn56/udpbroadcastrelay

Itar

Hi,

can someone give me a hint how the command looks like for Shellcmd/command prompt (pfsense 2.5.0 / APU2C4)?
With "find / -name 'udpbroadcastrelay'" I could find udpbroadcastrelay in "/usr/local/sbin/".
With Putty and "/usr/local/sbin/udpbroadcastrelay --id 1 --port 5353 --dev igb1 --dev igb1.12 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null" everything works perfectly but not in pfSene (command prompt) itself.

tman222

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

Hi,

can someone give me a hint how the command looks like for Shellcmd/command prompt (pfsense 2.5.0 / APU2C4)?
With "find / -name 'udpbroadcastrelay'" I could find udpbroadcastrelay in "/usr/local/sbin/".
With Putty and "/usr/local/sbin/udpbroadcastrelay --id 1 --port 5353 --dev igb1 --dev igb1.12 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null" everything works perfectly but not in pfSene (command prompt) itself.

Hi @itar - please take a look at my post above, I think you might be missing the /usr/bin/nohup command as part of the ShellCmd:

https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlans/37

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