Odbieranie danych multiemisji w określonym interfejsie

Question

tcmpdump może wyświetlać cały ruch multiemisji do określonej grupy i portu na etykiecie eth2, ale mój program w języku Python nie może tego zrobić. Program Python, działa na 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 

Kiedy używać innego programu do wysyłania pakietów multicast do eth2, to działa i drukuje pakiet. Ale nie widać całego bieżącego ruchu multiemisji. Jeśli uruchomię tcpdump na eth2 na tym samym porcie i grupy jako powyższego programu:

sudo tcpdump -i eth2 host 6.7.8.9 and port 52122 

widzi oba pakiety mogę wysłać z innego programu i wszyscy bieżącego ruchu multicast. Wydaje się, że to wyjście ...

# 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 

Dlaczego mój program nie może zobaczyć pakietów ze świata zewnętrznego? Jak mogę go zmodyfikować (lub coś innego), aby to naprawić?

Edit:

Powinienem wspomnieć, interfejs ten będzie ponad nie jest eth2 ale eth2.200 VLAN. (Lokalne komendy IP i tcpdump są uruchamiane z eth2.200, właśnie zmieniłem to w tym pytaniu, aby było prostsze.) Na podstawie this answer, które mogą być problemem?

Edit # 2:

netstat -ng gdy program jest uruchomiony pokazy eth2.200 subskrybowane 224.0.0.1 i 6.7.8.9`.

tshark -i eth2.200 igmp pokazuje trzy powtórzone 1.2.3.4 -> 6.7.8.9 IGMP 46 V2 Membership Report/Join group 6.7.8.9 podczas pierwszego uruchomienia programu. Gdy proces programu zostanie zabity, pokazuje 1.2.3.4 -> 224.0.0.2 IGMP 46 V2 Leave group 6.7.8.9. Istnieje również rzadki 1.2.3.1 -> 224.0.0.1 IGMP 60 V2 Membership Query, general, gdzie 1.2.3.1 jest bramą 1.2.3.4.

Nie wiem, czy to pomoże, ale tabela routingu wygląda następująco:

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 

Dziękujemy!

Answer 1

Wreszcie! Znaleziono this question na ServerFault, który adresuje to samo. Zasadniczo jądro nie przekazywało/odfiltrowało pakiety, ponieważ uważało, że adres źródłowy jest sfałszowany.

Zmienione ustawienia w /etc/sysctl.conf, aby dopasować:

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

uruchomiony ponownie i wszystko działa.