La multidiffusion UDP ne fonctionne pas

11

Multicast UDP sur Raspberry Pi

Je n'ai pas suffisamment réduit les choses pour savoir si mon problème est dû à Debian, Raspbian en particulier, ou si je manque complètement quelque chose.

J'ai une application python qui utilise la multidiffusion UDP pour faire savoir aux autres appareils du réseau que mon application est opérationnelle et disponible à une adresse IP spécifique.

Le groupe de multidiffusion UDP est 239.255.250.250 et le port est 9131. Si j'exécute tcpdump, je peux voir que le paquet que j'essaie d'envoyer est réellement l'envoi de données, mais je ne vois jamais rien arriver sur d'autres machines du réseau.

Il existe d'autres appareils qui utilisent ce même type de "balise" avec le même groupe de multidiffusion et le même port et je peux voir ces paquets passer sur d'autres machines. Le routeur n'a pas de pare-feu et je suis vraiment à court d'options à ce stade.

Voici les diagnostics de base que je sais exécuter. Le mauvais chksum udp semble que ce n'est probablement pas utile, mais je ne sais vraiment rien à ce sujet.

Sortie d'ifconfig

eth0      Link encap:Ethernet  HWaddr b8:27:eb:b2:79:12  
          inet addr:192.168.2.7  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1682 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1686 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:119105 (116.3 KiB)  TX bytes:169570 (165.5 KiB)

Sortie de tcpdump pendant que l'application est en cours d'exécution

    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
03:29:15.722653 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 221)
    192.168.2.7.33335 > 239.255.250.250.9131: [bad udp cksum 0xae84 -> 0xaabe!] UDP, length 193
    0x0000:  4500 00dd 0000 4000 0111 cb66 c0a8 0207  E.....@....f....
    0x0010:  efff fafa 8237 23ab 00c9 ae84 414d 5842  .....7#.....AMXB
    0x0020:  3c4d 4143 2d41 4444 523d 6238 3a32 373a  <MAC-ADDR=b8:27:
    0x0030:  6562 3a62 323a 3739 3a31 323e 3c2d 5555  eb:b2:79:12><-UU
    0x0040:  4944 3d32 3032 3438 3135 3937 3537 3734  ID=2024815975774
    0x0050:  3930 3e3c 2d53 444b 436c 6173 733d 5574  90><-SDKClass=Ut
    0x0060:  696c 6974 793e 3c2d 4d61 6b65 3d69 5275  ility><-Make=iRu
    0x0070:  6c65 426f 783e 3c2d 4d6f 6465 6c3d 5265  leBox><-Model=Re
    0x0080:  6d6f 7465 426f 783e 3c2d 5265 7669 7369  moteBox><-Revisi
    0x0090:  6f6e 3d30 2e31 3e3c 2d50 6b67 5f4c 6576  on=0.1><-Pkg_Lev
    0x00a0:  656c 3d47 4350 4b30 3032 3e3c 2d43 6f6e  el=GCPK002><-Con
    0x00b0:  6669 672d 5552 4c3d 6874 7470 3a2f 2f31  fig-URL=http://1
    0x00c0:  3932 2e31 3638 2e32 2e37 3a38 303e 3c2d  92.168.2.7:80><-
    0x00d0:  5374 6174 7573 3d52 6561 6479 3e         Status=Ready>
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

Sortie de netstat pendant l'exécution du programme

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:31144           0.0.0.0:*                           1510/dhclient   
udp        0      0 0.0.0.0:33335           0.0.0.0:*                           2089/python     
udp        0      0 0.0.0.0:68              0.0.0.0:*                           1510/dhclient   
udp        0      0 192.168.2.7:123         0.0.0.0:*                           1911/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           1911/ntpd  
Alex
la source
Pouvez-vous fournir la sortie de netstat -gn sur 2 hôtes?
UnX
Peut-être utile: superuser.com/questions/324824/…
cpugeniusmv

Réponses:

13

Je comprends que votre hôte, 192.168.2.7 envoie un paquet de multidiffusion au groupe 239.255.250.250 sur le port 9131

REMARQUE: je suppose cependant que les serveurs écoutent sur le port 9131. vous n'avez fourni aucune information à ce sujet.

De la sortie ifconfig, je peux voir que MULTICAST est activé et le tcpdump le confirme.

Assurez-vous d'abord que l'hôte exécutant les serveurs (celui qui reçoit le paquet de multidiffusion) a rejoint le groupe de multidiffusion.

Sur chaque type d'hôte de serveur:

netstat -gn

Si vous voyez votre adresse de multidiffusion, elle a rejoint le groupe. Sinon, alors quelque chose ne va pas avec votre programme serveur ou peut-être les paramètres du noyau.

Si le serveur a rejoint le groupe mais que vous ne voyez aucun paquet provenant du client, vérifiez sur votre routeur que vous avez activé igmp (votre routeur doit être capable d'igmp)

Par exemple, sur un routeur Cisco

enable
conf t
ip multicast-routing
For each interface involved.
int <NIC>
ip pim sparse-dense-mode

Si igmp est activé sur le routeur, recherchez les fonctionnalités de débogage pour suivre les paquets.

Côté serveur, lancez une capture de paquets:

tcpdump -i <NIC> host 239.255.250.250

Si vous ne voyez aucun paquet arriver, alors le paquet de multidiffusion n'est pas transmis (en supposant que

Ensuite, sur le client, envoyez un paquet de multidiffusion (utilisez le script dans le lien ci-dessous pour dépanner)

REMARQUE: le paquet UDP semble mal formé, donc vous ne savez pas si les serveurs pourront le lire. Vous pouvez utiliser le script dans le lien ci-dessous pour confirmer si le message dans tcpdump s'affiche ou non comme mal formé (ce n'est pas le cas dans mon cas)

Exemple de code python utilisant la multidiffusion:

/programming/603852/multicast-in-python

REMARQUE: j'ai utilisé ce script sur une raspi debian (pas raspbian et le serveur a reçu des paquets via le routeur - comme configuré ci-dessus - très bien)

Guide Linux: http://stlinux.com/howto/network/short-guide

Cisco: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_52_se/configuration/guide/3750scg/swmcast.html#wp1024278

UnX
la source
Réponse très longue et la plus petite partie est ce qui semblait être le problème. Le truc de dépannage que vous avez mentionné, je l'ai déjà fait, mais c'était après avoir posté cela. Tout avait l'air bien sur le serveur et le client. IGMP sur le routeur était le problème, mais ce paramètre était caché
Alex
2
votre description n'était pas assez claire pour donner une réponse directe, j'ai donc pensé que je pourrais écrire un mini guide de dépannage.
UnX
1

J'ai remarqué que cela peut également être un problème matériel et / ou pilote. J'ai utilisé la multidiffusion UDP (transmission et réception) sur mes RaspberryPI sans aucun problème - avec des programmes C, Java et / ou Python.

Cependant, je viens d'apprendre que la réception multidiffusion UDP NE FONCTIONNE PAS avec le joli petit adaptateur USB nano wifi d'EDIMAX - envoyer des travaux UDP (multidiffusion), recevoir également les propres messages (locaux).

les détails des clés USB de lsusb:

La réception multicast UDP ne fonctionne pas: ID 7392: 7811 Adaptateur sans fil EW-7811Un 802.11n Edimax Technology Co., Ltd [Realtek RTL8188CUS]

La réception multidiffusion UDP fonctionne correctement: ID 148f: 3070 Ralink Technology, Corp. Adaptateur sans fil RT2870 / RT3070

Michael
la source
fonctionne également: cette clé ASUS d'ID 0b05: 1791 ASUSTek Computer, Inc. Adaptateur WL-167G v3 802.11n [Realtek RTL8188SU]
Michael
0

J'ai rencontré un problème similaire où les paquets entraient et je pouvais les voir avec tcpdumpmais aucun programme ne pouvait recevoir les données.

Le problème dans ce cas était que j'avais l'habitude iptablesd'autoriser uniquement le trafic de mon sous-réseau local, 192.168.0.0/24mais bien sûr la multidiffusion vient à la 224.0.0.0/4place. Plutôt que d'ouvrir l'intégralité de ce sous-réseau (il se peut tout aussi bien qu'il n'y ait pas de pare-feu), j'ai simplement autorisé le trafic provenant de tous les hôtes sur le port UDP spécifique que j'utilisais pour la multidiffusion, et cela a résolu le problème.

Malvineous
la source
0

Pour nous, nous avons eu un problème similaire où le groupe de multidiffusion a été rejoint correctement, mais aucun message n'a été reçu.

Nous avons vérifié les paramètres igmp sur le routeur, qui semblaient être en ordre.

En fin de compte, nous sommes passés de l'utilisation de l'adresse de multidiffusion IPv6 à IPv4 et cela l'a résolue pour ce système particulier.

Adam Reis
la source