La multidifusión UDP no funciona

11

UDP de multidifusión en frambuesa pi

No he reducido las cosas lo suficiente como para saber si mi problema se debe a debian, raspbian específicamente, o si me falta algo por completo.

Tengo una aplicación de Python que utiliza UDP de multidifusión para que otros dispositivos de la red sepan que mi aplicación está en funcionamiento y disponible en una dirección IP específica.

El grupo de multidifusión UDP es 239.255.250.250 y el puerto es 9131. Si ejecuto tcpdump, puedo ver que el paquete que estoy intentando enviar está enviando datos, pero nunca veo nada en otras máquinas de la red.

Hay otros dispositivos que usan este mismo tipo de "baliza" con el mismo grupo y puerto de multidifusión y puedo ver esos paquetes en otras máquinas. El enrutador no tiene firewall, y estoy realmente sin opciones en este momento.

A continuación se muestra el diagnóstico básico que sé cómo ejecutar. Parece que el udp chksum malo probablemente no sea útil, pero realmente no sé nada al respecto.

Salida de 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)

Salida de tcpdump mientras la aplicación se está ejecutando

    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

Salida de netstat mientras el programa se está ejecutando

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
networking  python  udp  multicast 
— Alex
fuente
¿Puede proporcionar la salida de netstat -gn en 2 hosts?
— UnX
Que puede resultar útil: superuser.com/questions/324824/...
— cpugeniusmv

Respuestas:

13

Entiendo que su host, 192.168.2.7 está enviando paquetes de multidifusión al grupo 239.255.250.250 en el puerto 9131

NOTA: Sin embargo, supongo que los servidores están escuchando en el puerto 9131. No proporcionó ninguna información al respecto.

Desde la salida de ifconfig, puedo ver que MULTICAST está habilitado y el tcpdump lo confirma.

Primero asegúrese de que el host que ejecuta los servidores (el que recibe el paquete de multidifusión) se haya unido al grupo de multidifusión.

En cada tipo de host del servidor: 

netstat -gn

Si ve su dirección de multidifusión, se ha unido al grupo. Si no, entonces hay algún problema con el programa del servidor o posiblemente con la configuración del kernel.

Si el servidor se ha unido al grupo pero no ve ningún paquete entrante del cliente, verifique en su enrutador que haya habilitado igmp (su enrutador debe ser compatible con igmp)

Por ejemplo, en el enrutador Cisco

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

Si igmp está habilitado en el enrutador, busque características de depuración para rastrear los paquetes.

En el lado del servidor, inicie una captura de paquetes:

tcpdump -i <NIC> host 239.255.250.250

Si no ve ningún paquete entrante, entonces el paquete de multidifusión no se reenvía (suponiendo que

Luego, en el cliente, envíe un paquete de multidifusión (use el script en el enlace a continuación para solucionar problemas)

NOTA: el paquete UDP parece estar mal formado, así que no estoy seguro si los servidores podrán leerlo. Puede usar la secuencia de comandos en el enlace a continuación para confirmar si el mensaje en tcpdump se muestra con formato incorrecto o no (no lo están en mi caso)

Ejemplo de código python usando multicast:

/programming/603852/multicast-in-python

NOTA: Utilicé este script en un debian raspi (no raspbian y el servidor recibió paquetes a través del enrutador, como se configuró anteriormente, está bien)

Guía de 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
fuente
Respuesta muy larga y la parte más pequeña es lo que realmente parecía ser el problema. Las cosas de solución de problemas que ha mencionado, ya lo hice, pero eso fue después de publicar esto. Todo se veía bien en el servidor y el cliente. El problema era el IGMP en el enrutador, pero esa configuración estaba oculta
— Alex
2
su descripción no era lo suficientemente clara como para dar una respuesta directa, así que pensé que podría escribir una mini guía de solución de problemas.
— UnX
1

Noté que esto también puede ser un problema de hardware y / o controlador. Utilicé UDP de multidifusión (transmitir y recibir) en mis raspberryPI sin ningún problema, con los programas C, Java y / o Python.

Sin embargo, acabo de enterarme de que la recepción de multidifusión UDP NO FUNCIONA con el pequeño y agradable adaptador USB nano wifi de EDIMAX: el envío de UDP (multidifusión) funciona y también recibe los propios mensajes (locales).

Los detalles de las memorias USB de lsusb:

La recepción de multidifusión UDP no funciona: ID 7392: 7811 Edimax Technology Co., Ltd EW-7811Un Adaptador inalámbrico 802.11n [Realtek RTL8188CUS]

La recepción de multidifusión UDP funciona bien: ID 148f: 3070 Ralink Technology, Corp. Adaptador inalámbrico RT2870 / RT3070

— Miguel
fuente
también funciona: este dispositivo de ASUS con ID 0b05: 1791 ASUSTek Computer, Inc. Adaptador WL-167G v3 802.11n [Realtek RTL8188SU]
— Michael
0

Encontré un problema similar en el que entraban los paquetes y podía verlos, tcpdumppero ningún programa podía recibir los datos.

El problema en este caso era que solía iptablespermitir solo el tráfico de mi subred local, 192.168.0.0/24pero por supuesto, la multidifusión proviene en su 224.0.0.0/4lugar. En lugar de abrir toda la subred (es posible que no tenga un firewall), simplemente permití el tráfico de todos los hosts en el puerto UDP específico que estaba usando para la multidifusión, y esto solucionó el problema.

— Malvinoso
fuente
0

Para nosotros tuvimos un problema similar en el que el grupo de multidifusión se unió bien, pero no se recibieron mensajes.

Verificamos la configuración de igmp en el enrutador, que parecía estar en orden.

Al final, cambiamos de usar la dirección de multidifusión IPv6 a IPv4 y eso lo resolvió para ese sistema en particular.

— Adam Reis
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.