How can I get this UDP relay package for casting across VLANs?
-
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?
-
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.
-
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
-
@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.
-
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.
-
@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.
-
You tried Avahi?
https://www.youtube.com/watch?v=kYKfmS5_3r0
-
@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.
-
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
-
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.
-
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
-
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.
-
You probably need to NOHUP it too, something like:
/usr/bin/nohup /full/path/to/your_command > /dev/null &
-
@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.
-
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
-
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.
-
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
-
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.
-
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.
-
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
-
@stephenw10 It's still going great, and I submitted the request:
https://redmine.pfsense.org/issues/10818
-
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.
-
-
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.htmlSteve
-
@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.htmlSteve
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!
-
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
-
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.
-
Nice!
-
@tman222 @stephenw10 Yeah, it's awesome. Glad you figured it out. I was planning to respond to you but I just saw your messages as I was going into some work meetings.
-
@burntoc said in How can I get this UDP relay package for casting across VLANs?:
@tman222 @stephenw10 Yeah, it's awesome. Glad you figured it out. I was planning to respond to you but I just saw your messages as I was going into some work meetings.
Aaannnd......now it isn't working. It's odd, because I didn't change anything that I can see would affect this. I was tweaking a couple of DNS settings (not mDNS) and I noticed it shortly after, but even putting them back and checking that the relay is running it is no longer showing my groups in the other VLAN. I had stopped avahi because as you noted it was working fine without it, but even turning that back on hasn't fixed the issue. I'm not sure why it stopped, though there was an update to the Google Home app recently....
-
Actually that must be part of the issue. I just looked and the groups are still showing on my iPad, just not on my Android phone at the moment. Grrrr.....
UPDATE - Nah, they show up but can't cast to those groups any longer unless I connect to that VLAN.
-
Hi @burntoc - everything is still working fine here. I just checked on an iPhone and it does have the latest version of the Google Home app installed. What changes did you make to DNS? Also have you tried resetting your firewall states to see if that helps (i.e. forcing all the connections to be reestablished)? Come to think of it, I did have a bit of trouble the other night after I created a new group and then couldn't cast to it. However, after a few more attempts it did eventually start working and has worked fine since.
-
@tman222 said in How can I get this UDP relay package for casting across VLANs?:
Hi @burntoc - everything is still working fine here. I just checked on an iPhone and it does have the latest version of the Google Home app installed. What changes did you make to DNS? Also have you tried resetting your firewall states to see if that helps (i.e. forcing all the connections to be reestablished)? Come to think of it, I did have a bit of trouble the other night after I created a new group and then couldn't cast to it. However, after a few more attempts it did eventually start working and has worked fine since.
Just wanted to follow up on my last post real quick to confirm that everything is working is still working fine on Android based device as well for me (using latest version of Google Home app).
@burntoc - were you ever able to resolve the issues you were seeing?
-
@tman222 Thanks for following up - and confirming that your Android GH app is working okay. Mine is still not working well, though I've noticed that Home isn't working great in general atm (e.g. I ask it to play streams and they time out more often than not). I have one Google Home Hub in the IOT VLAN with my Chromecast audios, Google Home speakers, etc. and I wonder if something about the multicast address registration is not working properly. I've rebooted the firewall and the Google Home Hub but still no joy here. I'm pretty certain here weren't any other changes to my network. I have a couple of other things I probably have to prioritize above further troubleshooting, but worst case I'm planning on some troubleshooting no later than this weekend.
-
@burntoc said in How can I get this UDP relay package for casting across VLANs?:
@tman222 Thanks for following up - and confirming that your Android GH app is working okay. Mine is still not working well, though I've noticed that Home isn't working great in general atm (e.g. I ask it to play streams and they time out more often than not). I have one Google Home Hub in the IOT VLAN with my Chromecast audios, Google Home speakers, etc. and I wonder if something about the multicast address registration is not working properly. I've rebooted the firewall and the Google Home Hub but still no joy here. I'm pretty certain here weren't any other changes to my network. I have a couple of other things I probably have to prioritize above further troubleshooting, but worst case I'm planning on some troubleshooting no later than this weekend.
@burntoc - did you change any settings on your wireless access points or network switches?
-
@tman222 That's what I'm going to check, but I'm 99% sure I did not change any of that. I have 2 APs that trunk to the main switch, and I didn't mess with those APs, the trunks to the switch, or the trunk from the switch to the fireawall. No other mDNS or other changes, either.
-
Just wanted to follow up on this thread quick and mention that this is still tool is working great for me without any issues (despite several reboots of the firewall since the initial install and configuration). A great alternative to Avahi if one is looking to get Google Home speaker groups to work. Even though I have not been able to try this out yet, it may also be a suitable alternative for pimd to get Sonos speakers to work.
-
UPDATE 5/25/2023:
As of pfSense Plus 23.05,
udpbroadcastrelay
is now a formal pfSense package that can be added via the Package Manager.=====================
Just thought I would provide a quick set of instructions to get this package up and going (questions were asked in another thread).
README FIRST:
- Instructions on how to configure the package can be found on the creator's page on GitHub:
https://github.com/marjohn56/udpbroadcastrelay
- Before proceeding always make a backup of your firewall configuration first in case a mistake/misconfiguration renders your system inoperable.
INSTRUCTIONS - Please Read Updates Below As Well:
- Compile the updbroadcastrelay code from GitHub (see @stephenw10's post above for reference: https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlans/9) on a FreeBSD system or virtual machine (For pfSense 2.4.5p1 this should be FreeBSD 11.3). If you are not able to compile the code on your own, you can also download the attached archive file which contains a precompiled udpbroadcastrelay binary. Please note that this binary has been compiled under FreeBSD 11.3 and thus only tested to work with the current version of pfSense (at the time of this writing this is 2.4.5-p1).
udpbroadcastrelay_pfSense245p1.zip
UPDATE 2/18/2021:
With pfSense 2.5.0 now being available, @sfxdude has compiled the udpbroadcastrelay code to binary under FreeBSD 12.2 for pfSense 2.5.0. Please see this post:
UPDATE 3/14/2021:
It looks like this package has now been included upstream in FreeBSD, so no longer a need to compile on your own from source:https://www.freshports.org/net/udpbroadcastrelay/
https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlans/66-
Next, drop the compiled udpbroadcastrelay binary file into the /root/udpbroadcastrelay directory on your firewall.
-
Install the ShellCmd package on pfSense.
-
Configure the updbroadcastrelay based on your use case and configure the ShellCmd package to start it automatically on startup. Please see:
https://github.com/marjohn56/udpbroadcastrelay#usage
Below are two example commands to illustrate using the package to enable mDNS relaying between two network interfaces, igb0 and igb1:
/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb0 --dev igb1 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null
If using two VLAN's, e.g. 10 and 20:
/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb0.10 --dev igb1.20 --multicast 224.0.0.251 -s 1.1.1.1 -f > /dev/null
Additional details are also available further up on this thread.
-
Although I have not tried this out, I assume it would be ok to run multiple instances of the udpbroadcastrelay (with different
--id
defined) in case you want to enable mDNS and SSDP at the same time, for example. -
This only sets up the udp relaying between subnets. The necessary firewall rules are still required for devices on different subnets to actually talk to each other (once they have been discovered).
======================
I hope these instructions are useful for those looking to try this out. Please note that I'm not the creator and maintainer of this code base so will be limited with the amount of help I can provide.
-
@tman222 x-posting my reply from the other thread with some observations from my end.
“@tman222 thank you.
I ended up spinning a VM on a old Windows laptop and was able to get the binary working. It works like a charm! Great thing is that it doesn’t need any other packages like Avahi or PIMD ( I never had any 100% success with previously) nor does it require fiddling around with firewall rules. For the first time in 2 years, I have my Sonos working as I intend in my pfSense + Unifi ecosystem.
So far, I have the following tested and working correctly:
Controlling and playing to Sonos speakers across VLANs via the Sonos App v2
Airplay 2 (incl multi-room) works perfectly across VLANS.
LIFX app to manage bulbs across VLAN’s works great
Side effect - HomeKit also works across VLANs although I have only tested with anything else other than the LIFX bulbs. Now that I have my IoT network in working order, I feel like investing in more devices.
I just need to figure out a reliable way to keep the package running if/when pfSense reboots (eg via shellcmd).@tman222 Do you use Cloudflare DNS? Not sure I understand what the hard coded 1.1.1.1 source address in the package does? So far I’m not seeing any conflicts with their DNS, but will keep an eye out if anything breaks.”
Re:#5: Yes, I can confirm multiple instances of the process with a unique ID works. That’s how I have it running,
#6: Agree - this will be unique to everyone’s case based on their VLAN configuration, but in my instance, I only have one rule alllowing all traffic from My LAN to any. Does this open up any security risks?
-
From the man page:
A special source ip of -s 1.1.1.1 can be used to set the source ip to the address of the outgoing interface and the source UDP port to the same as the destination port. '-s 1.1.1.2' does the same but leaves the UDP ports unchanged. These values are notably required to cater for the Chromecast system.
Steve
-
@stephenw10 said in How can I get this UDP relay package for casting across VLANs?:
./udpbroadcastrelay
Maybe I missed it, but what is the command to quit/stop/kill it?