Estoy escribiendo una aplicación para obtener actualizaciones de multidifusión desde un dispositivo de medición de corriente que está conectado a mi LAN. El dispositivo envía paquetes al grupo de multidifusión 224.192.32.19:22600 cada pocos minutos y puedo leerlos bien desde uno de los hosts (una Raspberry Pi).
Lo extraño es que cuando intenté agregar un segundo host de escucha, no pude encontrar ningún tráfico de multidifusión de ese grupo en su interfaz.
El diseño de la red es el siguiente:
Toda la red está en la misma ubicación física, bajo la misma subred 192.168.xx. Entre el remitente y el receptor hay 2 enrutadores TP-Link WDR3600 que ejecutan DD-WRT y un conmutador gigabit TP-Link de 8 puertos "tonto" (utilizado como expansor de puertos). Todo está cableado vía ethernet.
Más detalles:
- Los hosts "NOK" incluyen una computadora portátil con Windows 7, una máquina virtual Linux conectada en puente en la misma computadora portátil y una computadora portátil con Linux diferente.
- conectar un host "NOK" directamente al conmutador tonto donde está el host "OK" no tiene ningún efecto
- conectarse directamente al enrutador secundario (1 "salto" de Ethernet más cerca de la fuente) no tiene ningún efecto
No puedo encontrar ningún tráfico IGMP para ese grupo en ninguno de los hosts, incluido el que funciona- Al espiar el tráfico de red para IGMP, puedo ver 2 solicitudes de unión enviadas
224.0.0.22cuando se inicia mi aplicación.
La membresía del grupo es registrada por el kernel y se muestra mediante
~ $ netstat -ng
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 224.0.0.1
eth0 1 224.192.32.19
eth0 1 224.0.0.251
eth0 1 224.0.0.1
El código Python que inicializa el socket desde la aplicación de escucha es este:
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind((self.mcast_group, self.mcast_port))
mreq = struct.pack("4sl", socket.inet_aton(self.mcast_group), socket.INADDR_ANY)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
¿Que me estoy perdiendo aqui? Simplemente ejecutar la aplicación de escucha en el host de trabajo fue suficiente para recibir el tráfico de multidifusión, ¿por qué no es el caso de los oyentes adicionales?
Respuesta1
Resulta que se trataba de un problema del enrutador; después de reiniciar el enrutador secundario, todos los hosts comenzaron a recibir los paquetes de multidifusión como se esperaba.
Yo diría que fue un error de DD-WRT o alguna corrupción estatal que comprometió la distribución del tráfico de multidifusión.