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

stephenw10

You tried Avahi?

https://www.youtube.com/watch?v=kYKfmS5_3r0

burntoc

@stephenw10 Yes, I've been using Avahi for quite a while. IIRC, I couldn't cast from my GUEST VLAN to IOT until I ran that. Casting has worked pretty well for a while. My biggest complaint, as I haven't yet added the Sonos and other devices that may pose other challenges, is that when I'm in Google Home I can't see or manage my groups from the Guest VLAN without running that UDP relay.

stephenw10

Testing it manually is not too hard. Install git in FreeBSD 11.3 then:

root@FreeBSD_11-3:/home/admin # git clone https://github.com/marjohn56/udpbroadcastrelay
Cloning into 'udpbroadcastrelay'...
remote: Enumerating objects: 32, done.
remote: Counting objects: 100% (32/32), done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 32 (delta 9), reused 18 (delta 3), pack-reused 0
Unpacking objects: 100% (32/32), 24.02 KiB | 572.00 KiB/s, done.
root@FreeBSD_11-3:/home/admin # cd udpbroadcastrelay/
root@FreeBSD_11-3:/home/admin/udpbroadcastrelay # ls
.git		.gitattributes	.gitignore	CONTRIBUTORS.md	LICENSE		Makefile	README.md	main.c		pkg-descr	usage-notes
root@FreeBSD_11-3:/home/admin/udpbroadcastrelay # make
cc -O2 -pipe -g main.c -o udpbroadcastrelay
root@FreeBSD_11-3:/home/admin/udpbroadcastrelay # ls
.git			.gitignore		LICENSE			README.md		pkg-descr		usage-notes
.gitattributes		CONTRIBUTORS.md		Makefile		main.c			udpbroadcastrelay
root@FreeBSD_11-3:/home/admin/udpbroadcastrelay # ./udpbroadcastrelay 
usage: ./udpbroadcastrelay [--id ID] [--port udp-port]
       [--dev dev1] [--dev dev2] [--dev devX]
       [-s IP] [--multicast ip1] [--multicast ipX]
       [-t|--ttl-id] [-d] [-f]
       [-h|--help]

Copy that binary to pfSense run it, see if it does what you need.

Steve

burntoc

It works great, but I've run into something odd. I was using shellcmd to have it run upon boot, but if I do that about a half dozen of my services fail to start after boot. I then have to start them manually. If I disable that item in shellcmd then they start fine. I tried earlyshellcmd just to test and they start fine as well, but the package doesn't show it is running now according to ps.

stephenw10

What command did you use exactly?

If you didn't set it to run in the background it can stop the service start scripts until that process is killed.

Steve

burntoc

So I've tried a couple of ways. The daemon supports an "-f" flag that will fork it and send it to the background. That's what I was originally doing when I noticed I still had the issue. I saw some chatter about using "&" (these references are all without the quotes) so I replaced "-f" with "&". It seems to work the same way, but the problem persists.

On the off chance launching it as a script mattered I copied the command to a .sh file and made it executable and used shellcmd to launch that instead of the command line flags. All of the above have produced the same results so far, and it only happens with shellcmd it seems.

stephenw10

You probably need to NOHUP it too, something like:
/usr/bin/nohup /full/path/to/your_command > /dev/null &

burntoc

@stephenw10 So here's the command I tried based on your comment:

/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb2.60 --dev igb1.70 --multicast 224.0.0.251 -s 1.1.1.1 /dev/null &

That produced the same result. Avahi, arpwatch, nuts, suricata, and pfblockerNG all fail to start on boot. I can start them afterwards, though.

stephenw10

Hmm, I would use the -f option since it provides it instead of &. The /dev/null is just to redirect any output that might otherwise spam stuff but you need > /dev/null to do that. You probably don't need that anyway.
If you kill the udpbroadcastrelay process when it's booted do the other services then start?

Steve

burntoc

So would the syntax look like this?

/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb2.60 --dev igb1.70 --multicast 224.0.0.251 -s 1.1.1.1 -f /dev/null

In my tests they've acted similarly, but I've not used nohup until you mentioned it.

stephenw10

I expect either:
/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb2.60 --dev igb1.70 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null

Or don't bother with sending output anywhere and just use:
/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb2.60 --dev igb1.70 --multicast 224.0.0.251 -s 1.1.1.1 -f

But try killing the process after it boots. The other services will then start if that is what you're hitting.

Steve

burntoc

I actually tried the second command you provided first, as I don't really need the output and it hung the services. As you suggested, killing it then allowed the services to start.

I tried one last time with the first command - and it looks like it may have worked! I'm not going to get another chance to reboot for a bit to test again, but I am optimistic enough to say thank you for your help with this. I'm not sure why it was hanging it, but it seems this approach may have addressed it.

burntoc

I snuck in a reboot while I had a moment and I can confirm it is working with the first command you provided. Thanks again, Steve.

stephenw10

Nice!

Let us know how that goes. You might open a feature request in redmine to create a package for it if it performs well.

Steve

burntoc

@stephenw10 It's still going great, and I submitted the request:

https://redmine.pfsense.org/issues/10818

tman222

Hi all,

This is an interesting thread - I had a couple questions:

Any particular reason 1.1.1.1 is used as the source IP instead of an IP address on the subnet that contains the chromecasts?
Can the UDP broadcast relay code also be compiled on pfSense or is a separate install of FreeBSD 11.3 required?

Thanks in advance.

stephenw10

Unclear why 1.1.1.1 is used there. It could just be an example IP.

Yes you need a separate FreeBSD install to compile it. There are no build tools in pfSense.
https://docs.netgate.com/pfsense/en/latest/development/compiling-software-on-the-firewall.html

Steve

tman222

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

Unclear why 1.1.1.1 is used there. It could just be an example IP.

Yes you need a separate FreeBSD install to compile it. There are no build tools in pfSense.
https://docs.netgate.com/pfsense/en/latest/development/compiling-software-on-the-firewall.html

Steve

Thanks @stephenw10 ! Regarding 1.1.1.1, looks like it's all explained here (should have read a bit closer):

https://github.com/marjohn56/udpbroadcastrelay#udp-broadcast-relay-for-linux--freebsd--pfsense--opnsense

I just wish they had used a different address than 1.1.1.1 since that's also the IP of Cloudflare's DNS -- makes it a bit confusing.

Once the code has been compiled, is there a recommended location (directory) to put the binary on pfSense?

Thanks again!

stephenw10

Ah, yes. Special IP. I agree, that's not a great choice. You can change that in the code, probably easier to live with it though.

You can put the binary anywhere in the path. I would probably put it in /root at least initially so it doesn't get overwritten.

Steve

tman222

@burntoc @stephenw10

Just wanted to follow up quick and validate that this works great! Compiled the code to binary on FreeBSD 11.3, moved it over to pfSense, and then used the command from Steve above to autostart it using ShellCmd (replacing dev devices as needed with my own):

/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb2.60 --dev igb1.70 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null

Everything starts up fine after a firewall reboot and Google Home (Casting) and Apple TV (Airplay) work without issues. Avahi is no longer needed, plus there's the added bonus that Google Home speaker groups now work properly if the mobile device is in a different network subnet as the speakers / chromecasts.

Thanks again guys! Hopefully this can be made into an official pfSense package soon.