Why does iftop show no bandwidth from a multicast IP but tcpdump does? ffmpeg also cannot capture from the multicast

1
votes

I ran into a puzzling problem when trying to receive a multicast IP (of a video from 239.193.140.11:1234).

When $tcpdump dst 239.193.140.11 -w capturedData.pcap, the packets are captured correctly.

eg, 11:05:25.357138 IP 192.168.34.34.46192 > 239.193.140.11.1234: UDP, length 1328

This means that my machine is receiving the multicast IP packets.

However, when $iftop -i any is run, iftop doesn't show any bandwidth from 239.193.140.11. Furthermore, when I try to capture the multicast packets with ffmpeg: $ffmpeg -i udp://239.193.140.11:1234?localaddr=192.168.34.34, no packets are captured.

Why is there a discrepancy between what tcpdump and iftop shows, and how to resolve it so that ffmpeg can capture correctly?

1
networkingffmpegvideo-capturemulticasttcpdump
what about if iftop is running while tcpdump is? what output from ffmpeg? – rogerdpack
"iftop doesn't show any bandwidth from 239.193.140.11" The multicast address, 239.193.140.11, is the destination address, not the source address. You would only ever see traffic to a multicast address, not from a multicast address. – Ron Maupin
If iftop is running while tcpdump is running, the output from ffmpeg still shows no packets are being captured. – Lenny

1 Answers

2
votes

Looks like Reverse Path Filter (rp_filter) is enabled, which is rejecting the packets. From my experience in a PROD environment, I can say that disabling the rp_filter enabled my client/listener application to pick up the packets. Use the below command to disable rp_filter:

 $echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

In the above, replace 'eth0' with the interface receiving the multicast if other than eth0, or alternately edit the rp_filter file and set the value to '0'