2012-12-12 13 views
5

tcmpdump può visualizzare tutto il traffico multicast su specifici gruppi e porte su eth2, ma il mio programma Python non può. Il programma Python, in esecuzione su Ubuntu 12.04:Ricezione di dati multicast su interfaccia specifica

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 

Quando uso un altro programma per inviare un pacchetto multicast a eth2, funziona e stampa il pacchetto. Ma non riesce a vedere tutto il traffico multicast corrente. Se corro tcpdump sul eth2 sulla stessa porta e gruppo del programma di cui sopra:

sudo tcpdump -i eth2 host 6.7.8.9 and port 52122 

vede sia i pacchetti che invio da un altro programma e tutto il traffico multicast corrente. Mi piace questo aspetto ...

# 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 

Perché il mio programma non può vedere i pacchetti dal mondo esterno? Come posso modificarlo (o qualcos'altro) per risolvere questo problema?

Edit:

Avrei detto, l'interfaccia di questo andare oltre non è eth2 ma eth2.200 una VLAN. (L'IP locale ei comandi tcpdump vengono eseguiti tutti con eth2.200, ho appena modificato quello in questa domanda per renderlo più semplice.) Sulla base di this answer quello potrebbe essere il problema?

Edit # 2:

netstat -ng quando il programma è in esecuzione spettacoli eth2.200 sottoscritto 224.0.0.1 e 6.7.8.9`.

tshark -i eth2.200 igmp mostra tre ripetuti 1.2.3.4 -> 6.7.8.9 IGMP 46 V2 Membership Report/Join group 6.7.8.9 all'avvio del programma. Quando il processo del programma viene ucciso, mostra 1.2.3.4 -> 224.0.0.2 IGMP 46 V2 Leave group 6.7.8.9. C'è anche un poco frequente 1.2.3.1 -> 224.0.0.1 IGMP 60 V2 Membership Query, general, dove 1.2.3.1 è il gateway di 1.2.3.4.

Non sono sicuro se vi aiuterà, ma la tabella di routing si presenta come:

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 

Grazie!

+1

Cosa dice 'netstat -ng' mentre si esegue il programma? –

+0

Non hai bisogno di un 'struct.pack (" = 4sl ", ...)' su 'mreq'? Rif: [UdpCommunication] (http://wiki.python.org/moin/UdpCommunication). –

+0

@NikolaiNFetissov: Durante l'esecuzione, sotto eth2, elenca: 'eth2 1 23.13.16.41',' eth2 2 6.7.8.9', 'eth2 1 224.0.0.1'. Il 23.13.16.41 è un altro gruppo a cui ho provato a iscriversi qualche tempo fa. – Albeit

risposta

7

Finalmente! Trovato this question su ServerFault che risolve la stessa cosa. Fondamentalmente il kernel non stava inoltrando su/stava filtrando i pacchetti perché pensava che l'indirizzo originario fosse falsificato.

modificato le impostazioni in /etc/sysctl.conf per abbinare:

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

riavviato e tutto funziona.

+2

La tua risposta mi ha salvato dopo 2 giorni di frustrazione! :) – tkarls

Problemi correlati