3

I have a CentOS 7.2 machine that is a VMware guest. I am subscribing to a multicast group and seeing all the multicast I'd expect, but my app is not seeing the contents of the stream. strace shows that it is waiting on a select() system call. What am I forgetting?

Here's what I've done:

  • Started a multicast sender on a remote host.
  • Built a CentOS 7.2 guest on a VMware host.
  • I stop and disable firewalld, and yum erase filewalld on the guest. iptables -L shows:

-

Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
  • I run : socat UDP4-RECVFROM:65000,ip-add-membership=239.31.82.10:10.0.54.210,fork STDOUT
  • I see no output from the command.
  • netstat -gn shows that it is subscribed to the multicast group.
  • selinux is disabled, in /etc/selinux/config I see: SELINUX=disabled. Yes, I have rebooted since that setting. Also I see: SELinux status: disabled from sestatus
  • tcpdump -n -nn -i eth0 host 239.31.82.10 shows packets hitting the interface from that IP, destined to the UDP port 65000.
  • Another host subscribed to the same multicast group sees data.
  • I build another VM guest, this time using CentOS 6.4, and it works fine. I see regular output from my multicast sender.
  • I build another VM guest, again using CentOS 7.2, and it works fine. This time I use a minimal install, however.

My issue looks like the firewall is blocking the packets, but as shown there is no firewall enabled.

The one significant difference between my not-working host and my working host is that the not-working host has two interfaces configured on it. But again, I am showing it as subscribed to the multicast group and I am showing packets hitting the interface. As well, I have shut down the second interface but that has not helped.

Thanks.

Improve this question
2
  • try to disable selinux to test if it is the culprit Commented Jul 29, 2016 at 20:34
  • 1
    Good catch. Forgot to mention that it's disabled. I've edited my text. Commented Jul 29, 2016 at 21:12

1 Answer 1

Reset to default
3

AGH! Famous words,

The one significant difference between my not-working host and my working host is ...

...for therein lie dragons!

AGH! Famous assumptions,

...But...

...for therein lies the root of all confusion!

The problem is Linux' networking reverse path filtering. The problem is that the packets are coming in on an interface and the routing table sees that the sending host's from address should come/go through the other interface (on which lies the default router). Therefore, the kernel was dropping the packets and not sending them to my app.

The IGMP reports were sent because, well, I told socat which interface I should use. And the routers and switches dutifully set up the multicast to go exactly where I told it to go. Ultimately, it was the kernel which was not happy.

The cheap and sleazy fix is to use sysctl to change net.ipv4.conf.all.rp_filter from 1 to 0, but that could cause unforeseen consequences if you're not careful (packets out of order, receiving packets that you don't want, packets coming in on the wrong interface). Better to make sure the routing table reflects the reality of what you're trying to do. So the other fix is to set /etc/sysconfig/network-scripts/route-iface so that there's a source or network route in it specifically for the multicast sender ip on that particular iface (ie, eth1 or what have you).

Improve this answer
1

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.