UDP Broadcast Relay

Started by marjohn56, February 03, 2020, 06:34:50 PM

Previous topic - Next topic


thnx, yeah I'm run-in udp-proxy-2020 now also and it works great.
I was a little hesitant because it was for pfsense instead of opnsense, but finally gave it a try.
Maybe UDP Broadcast Relay can have this udp-proxy-2020 option also? Would be nice to have this feature from the plugin's available instead of manually installing from terminal :-)

Btw: did you manage to get dup-proxy-2020 start automatically after a reboot? somehow that does not work for me and I have to start this tool manually after an reboot.
Deciso DEC850v2

https://file.io/jZtYnHbJkNCI

I have 2 services (UDP ports 1900 and 5353) so files are duplicated. Binary in sbin is from github repo (better not to trust and replace :) )

Its not perfect, but its ok, running as service even after reboot.

 :P
Great. I got the file and will try it out. thnx for the help.
Deciso DEC850v2

@mnaim, i noticed 1 missing file in your config in regards to mine:

etc/conf.d/udp_proxy_2020_1900  (with content udp_proxy_2020_1900_enable=YES)

i had etc/rc.conf.local   (with content udp_proxy_2020_enable=YES)

so I added
etc/conf.d/rc.conf.local  (with content udp_proxy_2020_enable=YES)

rebooted, but still not auto booted.... should the filename matter? I uses rc.conf.local as described https://github.com/synfinatic/udp-proxy-2020/tree/main/startup-scripts/pfSense
Deciso DEC850v2

If you copy all files to folders as in archive udp_proxy_2020 will start in 2 instance after reboot, you can check using ps aux | grep udp-proxy-2020 

I have another problem, process probably start before interfaces and in my case VLANs are initialized, need to postpone it little bit or setup service dependency.

this is the result (so maybe I should add a delay as you describe? never done that. how does that work?)

# ps aux | grep udp-proxy-2020
root          48357   0.0  0.0   12740    2216  0  S+   09:10    0:00.00 grep udp-proxy-2020


=======
after manual starting

# ps aux | grep udp-proxy-2020
root          47945   0.0  0.0   12752    2088  -  Ss   09:12    0:00.00 daemon: /usr/local/bin/udp-proxy-2020[48122] (daemon)
root          48122   0.0  0.1  731088   13592  -  S    09:12    0:00.05 /usr/local/bin/udp-proxy-2020 --port 9003 --interface igb1,wg0 --logfile /var/log/udp-proxy-2
root          73316   0.0  0.0   12740    2216  0  S+   09:13    0:00.00 grep udp-proxy-2020
Deciso DEC850v2

I found out, that unlike osudpbroadcastrelay udp-proxy-2020 cant forward multicast traffic, so its useless for some of my devices :/ https://github.com/synfinatic/udp-proxy-2020/issues/98

This upnp,ssdp are so crappy protocols...

Hey there,

I already posted a thread in the german forum here (https://forum.opnsense.org/index.php?topic=28465.0) but I think this might be better placed here. I beg your pardon for  the crosspost.

I use the plugin to transmit some multicast packets between my vlans. This is working great for normal vlans, but not for my OpenVPN. I connect some devices per OpenVPN. Those devices are in the OpenVPN network (10.10.0.0/24 in my case).
The plugin lets me select the networks to serve, but the OpenVPN-network is not listed, so I can't use it over vpn.

Does anyone have suggestions how to solve this issue?

Thanks alot

Quote from: dtloken on January 24, 2022, 11:51:02 PM
Running 22.1.r2 and I'm having some difficulty getting it to run:

2022-01-24T16:48:55-06:00
root /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay


Are there any known compatibility issues known at this moment?
I have the same issue, for all but the first rule...
No other logging available, unfortunately...
How can I find out what is causing this?
(Running on latest - OPNsense 22.7.1-amd64)

Login via ssh as root and try:
sh -x /usr/local/etc/rc.d/os-udpbroadcastrelay start

That should give you a hint at what exactly is failing.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

August 17, 2022, 11:24:17 AM #162 Last Edit: August 17, 2022, 11:37:02 AM by Mr. Happy
Quote from: pmhausen on August 17, 2022, 10:51:22 AM
Login via ssh as root and try:
sh -x /usr/local/etc/rc.d/os-udpbroadcastrelay start

That should give you a hint at what exactly is failing.
That gave me IP_ADD_MEMBERSHIP on rcv: Invalid argument
I had 192.168.70.255 as multicast address. Removed it and the line turned green and the service started.
Needed to add a rule to allow (in my case udp/5901) traffic to other vlan.
For my ChromeCast this was not needed to add additional firewall-rules (but the broadcast address there is: 224.0.0.251).

Does anyone have any good suggestions on how to best get the port in use by devices if documentation is unavailable?

I have some Harman Kardon speakers that I would like to reach from a separate VLAN but I got no idea which port I should be forwarding.
2x 23.7 VMs & CARP, 4x 2.1GHz, 8GB
Cisco L3 switch, ESXi, VDS, vmxnet3
DoT, Chrony, HAProxy + NAXSI, Suricata
VPN: IPSec, OpenVPN, Wireguard
MultiWAN: Fiber 500/500Mbit dual stack + 4G failover

--
Available for private support.
Did my answer help you? Feel free to click [applaud] to the left

Sorry to bring up an older thread.  I have some questions about this udpbroadcastrelay.  I understand how it cand replace avahi as a mdns repeater.  I'm not convinced on the use of it to replace pimd  or any form of pim sparse mode. The reason I say this is because udpbroadcastrelay can send out multicast traffic without regard to whether a device is part of the group or not increasing its packet overhead.  Pim-sm on the other hand has been designed to allow clients to join or leave multicast groups.
I am currently running avahi and  pimd on pfsense. I may take up opense in the near future.  My system is running without any issues with Sonos, HEOS,  Airplay , Apple screen sharing, and Miracast across multiple vlans.   Currently only firewall rules are to allow all.  Trying to get connectivity working first then lock it dowm

Marjohn56 maybe you could help.   
The issue I'm trying to resolve is with the DIAL multiscreen protocol my packet captures look like the post from thexy post 88
To answer thexy  the problem at hand is the server needs to send it's reply to client doing the search via tcp at the client ip address and application port.   From your capture listed the server is seeing the request from the relay, but the source ip address and port were changed during the relay, so the client never establishes the connection.
I am unclear on the command string to have the relay maintain the source ip and port that is critical.

MKnusperer is also describing the same issue in post 122.  Others that are having issues with TVs Roku's chromecasts.... are probably having problems with this DIAL multiscreen protocol.
If the code could parse the ssdp packet  for the.      ST DIAL Multiscreen  line maybe it could be handled differently
As a side note if you start DIAL multiscreen server client connection while in the same vlan and then move the client to a different vlan it's possible to maintain the connection,