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:

    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.

  • Netgate Administrator

    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?


  • @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.

  • Netgate Administrator

    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 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.

  • Netgate Administrator

    You tried Avahi?

    Youtube Video

  • @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.

  • Netgate Administrator

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

    root@FreeBSD_11-3:/home/admin # git clone
    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	LICENSE		Makefile	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		pkg-descr		usage-notes
    .gitattributes		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]

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


  • 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.

  • Netgate Administrator

    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.


  • 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.

  • Netgate Administrator

    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 -s /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.

  • Netgate Administrator

    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?


  • So would the syntax look like this?

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

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

  • Netgate Administrator

    I expect either:
    /usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 5353 --dev igb2.60 --dev igb1.70 --multicast -s -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 -s -f

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


  • 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.

  • Netgate Administrator


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


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

Log in to reply