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

burntoc

So I've not built a package for pfSense before, but I'm very interested in this one here as it sounds from the plugin discussion in a similar FreeBSD-based firewall that it works quite well for cross VLAN Chromecast needs - even group discovery which is where most all the other solutions currently fall down. There's a thread that goes into how it handles the approach differently, and there's even a pre-built package. There's a Github link here as well:

https://github.com/marjohn56/udpbroadcastrelay

I have to build it if I use the link, and as I said I've not done that before on pfSense. Is this straightforward to do? If not, and the pacakage is out there and it is also for this other similar FreeBSD firewall is it likely to work here?

burntoc

So in short:

Got some help in the other forum
The other pkg wouldn't work as it had install scripts incompatible with pfS
I was able to extract the package within (as I couldn't figure out how to make it from Github)
and it seems to be working pretty brilliantly when I launch it from the command line.
Now I can see my Chromecast groups from the other VLAN.

stephenw10

Build the binary in FreeBSD first, copy it across and make sure it runs.

However if you just needs Chromecast discovery have you tried pimd?

Steve

burntoc

@stephenw10 I did have tried it,but I haven't found a clear enough guide regarding how I should configure the settings to make it work for my basic use case. I figured I would bind it to the VLAN I want to cast and discover from as well as the VLAN that has my Chromecasts, but I'm not sure about the BSR Candidates (don't think I need this), RP Candidates, etc.

stephenw10

In other SSDP applications we have seen it only requires the interfaces involved enabled. You need to have appropriate firewall rules in place of course.

burntoc

@stephenw10 Hmmm.....I just killed that other daemon and tried PIMD. I bound it to the two interfaces involved and it didn't work. My casting from network is a "lower" IP range than my "players" network so I also tried changing the DR priority to make the casting network a 2 instead of the default 1. Both tests failed. To be clear, I'm very specifically testing with Chromecasts, and it looks like it does some really funky stuff, including changing source/destinations to 1.1.1.1 and other stuff.

The udpbroadcastrelay is working perfectly, FWIW, though I'd certainly like to find something more "core" to pfSense that would work as well.

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