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.
-
This post is deleted! -
@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/nullor
/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 -
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!
-
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 bindNot sure what would already be using 239.255.255.250:1900 or how to go about debugging from here.
Any pointers greatly appreciated
-
did you do a ps to check if it is already running?
-
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 62676I'll try temporarily powering down all other devices on that subnet and see if that helps
-
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 -
@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.
-
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.
-
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 -dOf 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.
-
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
-
Took a look at this as i was hoping it could help me overcome what PIMD seemingly could not, that is the initial discovery of SONOS devices on other VLANS. My set up was working fine once the controller had been connected to the SONOS VLAN and cached the ip addresses.
Unfortunately it does not. Followed what seems to be the fairly straightforward step by step guide by Qinn in post 55 and everything seems to work but nothing is discovered when i restart the pfsense.
Shellcmd per below
is there any way i can check it is properly running? other than SONOS detection working :)
-
@spaceboy - a few suggestions based on my trial and error experiences.
SSH to the console and check if the process is running:
[2.5.1-RELEASE][user@pf.internal.xxx.net]/home/user sudo ps | grep udpbroadcastrelay 13600 u0- S 0:02.44 /usr/local/sbin/udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -fCheck the path to the udbbroadcastrelay executable:
find / -name updbroadcastrelayMy working shellcmd entry is:
/usr/bin/nohup /usr/local/sbin/udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -f > /dev/nullRun pfTop From the diagnostics menu and filter on port 1900. You should be able to see your Sonos devices periodically connecting:
Also check that you don't have anything else on pfSense running a process bound to UDP/1900 on the same subnet/vlan. I initially had UPnP/NAT-PMP running for the XBox that's on the same subnet as my Sonos devices. That stopped udpbroadcastrelay from working so I made an executive decision that my kids could live without being able to host games and disabled UPnP for the Xbox
Hope that helps
-
@captaincathode thanks for the pointers, i think it helped a bit. linux doesnt really like me much so took me a little while to work through this.
i think its running on the pfsense now. in the console i see
for me executing that command to check the path to the udbbroadcastrelay executable returns nothing but i don't know if this is some result of me ssh'ing via admin or what? i also noticed the sudo command wasnt needed on the previous and i understand just enough to know thats related to the admin account.
I moved the executable from /root to /usr/local/sbin to match yours but i kept it in a subfolder so my shellcmd is
and in pftop i see
which seems to me to be good.but the result is still the same. nothing found by controllers on either windows, android or ios. so i guess whatever the problem is it was probably the same for pimd and that was working too.
my uneducated thought process says there must be something else on the network blocking the broadcast. i have a few switches and a unifi controller running the wireless AP's. is it possible any one of these could be blocking the multicast?
-
@spaceboy you’re saying you have Unifi deployed. Do you by chance have the “Auto Optimize” function or “Block LAN to WLAN multicast and broadcast” enabled? These might be the culprit.
Otherwise, you might want to look into:
- Whether your interfaces (vlans) match in the shellcmd command
- Firewall rules that block communication
-
@mg85 thanks, i do have Auto Optimize enabled but not the second.
Also i previously had this working under PIMD once the SONOS controller cached the SONOS devices ip addresses so i don't think its firewall rules.
To be honest i have given up on this for now. I believe i did try with my Sonos One wired into one of the switches to try and determine whether unifi was to blame and i don't think it worked. So i feel it may be more than unifi.
I'm also questioning whether IOT stuff and Sonos devices need seperate VLANs anyway. it was a nice little project but i'm not certain its worth the effort given the large number of ports i have seen people posting about need to have open even once multicast is working. Actually on that point, i'd be interested in understanding people's driver for segregating SONOS devices like this.
Hope to give this another try at some point. Ta
-
This was an immensely helpful thread for me. Yet I had problems still with discovery. It turns out that I needed to do additional work because I have Captive Portal setup on my IoT VLAN
I resolved that issue here: https://forum.netgate.com/topic/164733/captive-portal-causing-sendto-permission-denied-errors-with-udpbroadcastrelay
Leaving a reference to it here. Maybe it'll help someone else. -
Super helpful thread!
I have aVLAN for IoT devices and found this thread to help setup the "Bonjour/Chromcast/mDNS" broadcast between my main vlan and IOT vlan.
After starting the
udpbroadczatrelayI was seeing devices on my vLAN appear, albeit slowly, and periodically disappearing. I used Bonjour Browser (Discovery app from the OSX App store) on my Mac to monitor it. I also ranavahi-browse -aon a wired LAN device to watch the comings and goings of the iOT devices.One minute they were there, the next they were gone and did not come back.
I also could not use the
<my_iot_device>.localdns lookups for those IOT devices from my main LAN (.locallook up also use mDNS).I then put udpbroadcastrelay into debug mode (
-d) and only saw traffic goingLAN vlan -> my IOT vlan, but not the other way around. So no broadcast traffic being received into updbroadcastrelay from the IOT vlan.I then added a rule to my firewall in
Firewall > Rules > IOT(where IOT is my vlan interface) to allow incoming traffic to theIOTvlan Interface, from theIOT net, with destination being the broadcast IP (224.0.0.251) and the broadcast port (5353):
And everything started working! All my devices are now rock solidly discoverable, and the
.locallook ups work fine!It still does not explain why without the rule the devices were showing up intermittently, but it all seems to work now!
Thanks to everyone that added to this thread! -
What rules did you have there before? I assume you were seeing blocked traffic on IOT?
I expect to need the IP options flag set in a rule for multicast traffic like that.
Steve
