Using udpxy to proxy multicast from LAN to WAN?

[rentahero]

Hi,
I'm trying to configure my router (GL-MT300N-V2 running LEDE 17.01) to accept multicast UDP/RTP streams from an IPTV device and convert it to unicast TCP. It seems like udpxy is perfect for this, but I seem to be running into some configuration issues. Here's what I've got so far:

• I've got the IPTV device connected on the LAN port, and the router connected to the rest of my network on its WAN port. I don't want another DHCP server on the network, and I hope to use avahi to connect via .local later. However, my IPTV device wants an IP address from DHCP, so it can take one from the router.
• I've opened the following ports on WAN's firewall: 22, 80, 8080, 8888. I can configure the router on ports 22 (SSH) and 80 (LuCI).
• I've got udpxy installed and running on port 8888. If I go to the status page, it comes up just fine.
• When I try to connect to the multicast stream in VLC by entering http://<router's WAN IP>:8888/udp/239.255.42.42:5004/ I don't get a video stream (but VLC also doesn't seem to complain... it just plays nothing and stops).

I don't remember the exact command I used to start up udpxy, but it was something like this:
udpxy -p 8888 -T -S -a eth0.2 -m br-lan

I must admit, I'm at a bit of a loss as far as how to debug why I'm not getting anything. As I understand it, when using udpxy, the traffic would be transmitted from the input port 5004, and gets proxied to port 8888 on the WAN port. Is that a misconception, or do I need to open more ports on the WAN?

I'm doing this for a few reasons:

1. When I connect this device to my network in multicast mode, it seems to bring down my home network. I hope to be able to bring this setup to other locations and not worry about bringing down the entire network.
2. I'd like to have the packets transmitted over TCP so that there's less chances of packet loss.
3. The IPTV box doesn't support mDNS in any form, and my goal was to have a few Raspberry Pis just able to find the IPTV box on any network with zero configuration (but not deal with multicast).

I know this setup takes extra bandwidth, but I'm less worried about the bandwidth and more worried about the "multicast kills my network, and might kill others when I bring this setup" aspect of the current situation. Any help would be very much appreciated!

EDIT: I should add that I went through this:
https://openwrt.org/docs/guide-user/network/wan/udp_multicast
(and a few other guides), but they tend to be geared toward the UDP multicast traffic coming through the WAN port, not from LAN to WAN, so I wasn't fully sure what needed to be done as far as firewall rules, etc.

[Pilot6]

udpxy is not good for "IPTV devices", because play list needs to be changed.

For such devices the best solution is to use port bridging. The second choice is using igmpproxy.

Also consider using 'igmp_snooping" to avoid "bringing down your home network".

[rentahero]

Hi,
Thanks for following up. I probably miscategorized the device as IPTV... the device is a Lenkeng LKV373A HDMI to RTP box, so the output looks like an IPTV channel on multicast. It's always outputting multicast traffic on port 5004 to 239.255.42.42.
I think I figured out the problem just now, actually. The LKV373A sends some malformed packets, which ffmpeg has been updated to support, but I suspect udpxy may struggle with when it converts the packets.
I brought down the firewall of the router (because I realized it really doesn't need to be on, anyway) and verified that I see the same result (I do), and realized that I probably should run udpxy with -v to see what udpxy is producing.
When I connected to something other than 239.255.42.42:5004, I got a result of udpxy waiting for data (and VLC on my host PC doing likewise) for a number of seconds before it gave up. When I connected to 239.255.42.42:5004, then it saw one 1316 byte packet and gave up.

2018-08-13 22:35:13.921210 CDT	S(4104)	No children exited since last check
2018-08-13 22:35:13.921677 CDT	S(4104)	Got 1 requests
2018-08-13 22:35:13.921975 CDT	S(4104)	Accepting new connection
2018-08-13 22:35:13.922344 CDT	S(4104)	Accepted socket=[8] from (host's IP address here):60334 n=1/nmax=16
2018-08-13 22:35:13.922668 CDT	S(4104)	Accepting new connection
2018-08-13 22:35:13.923002 CDT	S(4104)	Nothing more to accept
2018-08-13 22:35:13.923313 CDT	S(4104)	accept_requests: Sockets accepted: [1]
2018-08-13 22:35:13.923601 CDT	S(4104)	Waiting for input from [3] fd's, with timeout
2018-08-13 22:35:13.923927 CDT	S(4104)	No children exited since last check
2018-08-13 22:35:13.924244 CDT	S(4104)	Got 1 requests
pre-process sockets [1]: 8
2018-08-13 22:35:13.924567 CDT	S(4104)	acting on accepted socket [8] (1/1)
2018-08-13 22:35:13.927694 CDT	S(4104)	Reading command from socket [8]
2018-08-13 22:35:13.929595 CDT	S(4104)	HTTP buffer [154 bytes] received
GET /udp/239.255.42.42:5004 HTTP/1.1
Host: (router's WAN IP here):8888
User-Agent: VLC/2.2.2 LibVLC/2.2.2
Range: bytes=0-
Connection: close
Icy-MetaData: 1

2018-08-13 22:35:13.931948 CDT	S(4104)	Request=[udp/239.255.42.42:5004], length=[22]
2018-08-13 22:35:13.934246 CDT	S(4104)	Command [udp] with params [239.255.42.42:5004], tail [] read from socket=[8]
2018-08-13 22:35:13.936769 CDT	S(4104)	udp_relay : new_socket=[8] param=[239.255.42.42:5004]
2018-08-13 22:35:13.939357 CDT	S(4104)	Added client: pid=[4231], maddr=[239.255.42.42], mport=[5004], saddr=[(host's IP address here)], sport=[60334]
2018-08-13 22:35:13.942087 CDT	S(4104)	process_requests: closing accepted socket [8]
2018-08-13 22:35:13.944197 CDT	S(4104)	Processed [1/1] accepted sockets
newly-accepted sockets [1]: 2018-08-13 22:35:13.946167 CDT	S(4104)	-1
2018-08-13 22:35:13.947114 CDT	S(4104)	All accepted sockets processed
2018-08-13 22:35:13.949302 CDT	S(4104)	Client process=[4231] started for socket=[8]
2018-08-13 22:35:13.950113 CDT	c(4231)	Waiting for input from [2] fd's, NO timeout
min socket buffer = [65536], max space to use = [1500], Rmsgs = [1]
2018-08-13 22:35:13.951293 CDT	c(4231)	Setting up multicast listener
2018-08-13 22:35:13.952829 CDT	c(4231)	current receive buffer size is [163840] bytes for socket [5]
2018-08-13 22:35:13.954906 CDT	c(4231)	multicast-group [ADD]
2018-08-13 22:35:13.956378 CDT	c(4231)	Mcast listener socket=[5] set up
2018-08-13 22:35:13.958399 CDT	c(4231)	min socket buffer = [65536], max space to use = [1500], Rmsgs = [1]
2018-08-13 22:35:13.959796 CDT	c(4231)	Data buffer will hold up to [1] messages
2018-08-13 22:35:13.962008 CDT	c(4231)	UDP stream, RTP check enabled
2018-08-13 22:35:13.963919 CDT	c(4231)	socket 5: RCV timeout set to 5 sec, 0 usec
2018-08-13 22:35:13.966850 CDT	c(4231)	socket 5: SEND timeout set to 5 sec, 0 usec
2018-08-13 22:35:13.968909 CDT	c(4231)	current send buffer size is [44800] bytes for socket [8]
2018-08-13 22:35:13.970210 CDT	c(4231)	current receive buffer size is [163840] bytes for socket [5]
2018-08-13 22:35:13.971746 CDT	c(4231)	send buffer size set to [163840] bytes for socket [8]
2018-08-13 22:35:13.973907 CDT	c(4231)	Sent HTTP response code=[200], reason=[OK] to socket=[8]
HTTP/1.1 200 OK
Server: udpxy 1.0-23.10 (prod) standard [Linux 4.4.92 mips]
Content-Type:application/octet-stream


2018-08-13 22:35:13.976414 CDT	c(4231)	Relaying traffic from socket[5] to socket[8], buffer size=[2048], Rmsgs=[1], pauses=[0]
2018-08-13 22:35:13.978490 CDT	c(4231)	read_data - EOF
2018-08-13 22:35:13.979846 CDT	c(4231)	Exited relay loop: received=[-1], sent=[0], quit=[0]
2018-08-13 22:35:13.981284 CDT	c(4231)	multicast-group [DROP]
2018-08-13 22:35:13.983610 CDT	c(4231)	Mcast listener socket=[5] closed
2018-08-13 22:35:13.986019 CDT	c(4231)	Child process=[4231] exits with rc=[0]
2018-08-13 22:35:13.988947 CDT	S(4104)	*** Caught SIGCHLD (18) ***
2018-08-13 22:35:13.989409 CDT	S(4104)	Waiting on exited children
2018-08-13 22:35:13.989777 CDT	S(4104)	Client [4231] has exited.
2018-08-13 22:35:13.990093 CDT	S(4104)	Deleted client: pid=[4231]
2018-08-13 22:35:13.990382 CDT	S(4104)	Cleaned up 1 children, 0 still running
2018-08-13 22:35:13.990676 CDT	S(4104)	INTERRUPTED, yet will continue.
2018-08-13 22:35:13.990975 CDT	S(4104)	Waiting for input from [2] fd's, NO timeout

So it seems it received some data it didn't like and killed the child process and sits, waiting expectantly for something new to happen with no traffic coming without a restart.
I've got a different HDMI to multicast device, so I'll try and see if udpxy works as expected with that device and see what the differences are in the debug output.

[rentahero]

Turns out the problem was with the Lenkeng device. OpenWRT is working perfectly for this. When I put in a different HDMI to RTP streaming device, the problems went away.

EDIT: I've got the Lenkeng device working using the following iptables rule (from danman.eu, with a slight modification for my LEDE install):
iptables -t mangle -A PREROUTING -p udp -m length --length 28 -j DROP
For some reason the raw table doesn't exist in my setup (?), so I had to change it to mangle, but it works just fine this way, so there you go. Thought this might help someone out later.