I am setting up video streaming.

In local network, there are two devices streaming video over UDP multicast. One is regular computer with Linux (streaming to, port 9200), second one is special DVB-S streamer (streaming to, port 9200). There are several IPTV set-top boxes in the network, which are able to play streams from either source. There are also some Cisco switches for multicast filtering, but I am not able to check their configuration.

On different computer (running Ubuntu 12.04) I would like to capture the stream, preferably using VLC or FFMPEG. From the computer streamer ( it works, but from special streamer ( I get no stream.

What I tried

I tried to narrow down the problem and tried to capture raw UDP datagrams with socat and tcpdump. If I run following command, I get valid video in video.dump file:

> socat UDP4-RECVFROM:9200,ip-add-membership= - > video.dump

When I simultaneously run tcpdump, I see incoming datagrams:

> sudo tcpdump -i eth1 
18:00:39.059824 IP > UDP, length 1316
18:00:39.060789 IP > UDP, length 1316

When I try to run same commands for the special streamer (just change the IP membership address for socat to, tcpdump shows incoming datagrams from, but video.dump file is empty.

What can be the reason that socat doesn't see the datagrams that are clearly coming?

Update on 4 March 2014:

I just found out that there are different IP ranges in the network:

Computer streamer: /
"Special" streamer: /
Computer on which I am trying to grab stream: /

When I change IP address of the last to 192.168.85.x /, I can catch streams from the "Special" streamer, but not from the computer streamer.

So the question changes to: is it possible to set socat, VLC or FFMPEG to accept also multicast streams that have a source address outside the range of the Ethernet interface?

  • The packets are sent to the multicast group but you are telling socat to join group Could this be the problem?
    – scai
    Commented Mar 1, 2014 at 17:46
  • @scai I made some mistakes when copying addresses from terminal, sorry about that. Now the question contains correct addresses. Commented Mar 1, 2014 at 18:02

1 Answer 1


tcpdump invoked without -p switches a NIC into promisc mode - apparently some higher level filtering kicks in, preventing socat from receiving the traffic.

One of the "usually guilty" suspects is rp_filter - do you have a route for both the source networks via eth1? I guess you might have default gw via eth0. Either add the missing route, or disable rp_filter on eth1 interface.

In OP case:

ip r a dev eth1


sysctl -w net.ipv4.conf.eth1.rp_filter=0
  • Yes, the problem was in missing route, I just forgot to update the question. Thank you. Commented May 18, 2018 at 21:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .