CODEWITHSUNDEEP
pythonsocketsmulticastpackettcpdump
Albeit
Albeit

Reputation: 748

Receiving multicast data on specific interface

tcmpdump can view all the multicast traffic to specific group and port on eth2, but my Python program cannot. The Python program, running on Ubuntu 12.04:

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

# Multicast port is 52122
sock.bind(('', 52122))

# Interface eth2 IP is 1.2.3.4, multicast group is 6.7.8.9
mreq = socket.inet_aton('6.7.8.9')+socket.inet_aton('1.2.3.4')
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)

while True:
    print '\nwaiting to receive message'
    data, address = sock.recvfrom(1024)
    print data

When I use another program to send a multicast packet to eth2, it works and prints the packet. But it fails to see all the current multicast traffic. If I run tcpdump on eth2 on the same port and group as the above program:

sudo tcpdump -i eth2 host 6.7.8.9 and port 52122

it sees both the packets I send from another program AND all the current multicast traffic. It's output looks likes this...

# Packet sent from my other program
09:52:51.952714 IP 1.2.3.4.57940 > 6.7.8.9.52122: UDP, length 19
# Packet send from the outside world
09:52:52.143339 IP 9.9.9.9.39295 > 6.7.8.9.52122: UDP, length 62

Why can't my program see the packets from the outside world? How can I modify it (or something else) to fix this?

Edit:

I should have mentioned, the interface this going over is not eth2 but eth2.200 a VLAN. (The local IP and the tcpdump commands are all run with eth2.200, I just changed that in this question to make it simpler.) Based on this answer that could be the problem?

Edit #2:

netstat -ng when the program is running shows eth2.200 subscribed to 224.0.0.1 and 6.7.8.9`.

tshark -i eth2.200 igmp shows three repeated 1.2.3.4 -> 6.7.8.9 IGMP 46 V2 Membership Report / Join group 6.7.8.9 when the program first starts. When the program process is killed, it shows 1.2.3.4 -> 224.0.0.2 IGMP 46 V2 Leave group 6.7.8.9. There is also an infrequent 1.2.3.1 -> 224.0.0.1 IGMP 60 V2 Membership Query, general, where 1.2.3.1 is 1.2.3.4's gateway.

Not sure if it will help, but the routing table looks like:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         1.2.5.6         0.0.0.0         UG        0 0          0 eth1
1.2.3.0         0.0.0.0         255.255.255.240 U         0 0          0 eth2.200

Thank you!

Upvotes: 5

Views: 6686

Answers (1)

Albeit
Albeit

Reputation: 748

Finally! Found this question on ServerFault that addresses the same thing. Basically the kernel was not forwarding on / was filtering out the packets because it thought the sourced address was spoofed.

Changed the settings in /etc/sysctl.conf to match:

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.ip_forward = 1

Rebooted and everything works.

Upvotes: 7

Related Questions