recepción de multidifusión en un servidor con múltiples interfaces (Linux)

Para recibir una multidifusión en mi no por defecto NIC (DVB) Yo lo siguiente:recepción de multidifusión en un servidor con múltiples interfaces (Linux)

abrir un zócalo (AF_INET, SOCK_DGRAM)
unirse a la dirección de multidifusión con IP_ADD_MEMBERSHIP en la interfaz DVB
obligar a la dirección de multidifusión (tenga en cuenta que un error común es unir "0.0.0.0" y luego recibir en ese socket incluso multidifusión no interesa) y el puerto

en este momento, la única forma de recibir los paquetes de multidifusión necesarios es agregar en la tabla de enrutamiento una regla para llegar a la red donde está el remitente (otra red) a través del dvb, como si el dvb necesita responder al remitente de multidifusión; digamos una especie de modo de multidifusión de emisor de origen. Alguien sabe lo que está pasando? El problema es molesto para mí porque, en principio, no conozco la ip del remitente.

Fuente

2011-03-30 Gaetano Mendola

Parece que el filtro rp_filter de recorrido inverso le molesta. Esto arroja paquetes si llegan a una interfaz que no tiene una ruta para la dirección de origen.

Puede desactivarlo por interfaz con sysctl /proc/sys/net/ipv4/conf/<if>/rp_filter.

Fuente

2011-03-30 11:01:58 caf

esto parece ser la solución, también encontré información útil en esta página http://ifup.org/2011/02/03/reverse-path-filter-rp_filter-by-example/ – thrantir

Eso funcionó, sin embargo tuvimos que deshabilite rp_filter no en la interfaz que recibe la multidifusión, sino en la interfaz utilizada en la tabla de enrutamiento de manera predeterminada. –

Desafortunadamente, el enlace de @ thrantir ya no es válido. –

unen la dirección de multidifusión

Eso es definitivamente mal. Debe vincularse a una dirección IP real de un adaptador real, o 0.0.0.0.

nota de que un error común es unir "0.0.0.0"

Eso no es un error. Es el procedimiento correcto a menos que solo desee escuchar una dirección IP.

y luego recibir en ese socket incluso de multidifusión no está interesado en

No sé lo que esto significa.

, en principio, no sé el IP del emisor

La dirección IP del remitente de cualquier datagrama UDP está disponible a través de la API de sockets.

Fuente

2011-03-30 09:44:27 EJP

No necesita vincular la dirección de multidifusión, si enlaza la dirección IP del adaptador real no recibirá ningún paquete de multidifusión, si se une a 0.0.0.0 está abriendo su filtro IP a cualquier multidifusión. Para tener el filtrado de software perfecto basado en la IP de destino (en este caso, la dirección de multidifusión) y luego recibir solo esa "multidifusión", debe * enlazar * la multidifusión. Le sugiero que lea el capítulo de multidifusión en UNP. –

@Gaetano Mendola: Lo leí hace 13 años gracias. No funciona en Windows y no tiene sentido w.r.t. la definición aceptada de 'atar'. – EJP

El hecho de que no funciona en Windows no significa que sea incorrecto. Windows IP stack no es famoso por ser estándar, también tenga en cuenta que he puesto mi pregunta: linux.Por otra parte, en nuestro middleware somos conscientes de ello y, en caso de que se defina WIN32, vinculamos la dirección IP de la interfaz, pero nuevamente eso es incorrecto si tenemos una "buena" pila de IP. –

recepción de multidifusión en un servidor con múltiples interfaces (Linux)

Respuesta

Cuestiones relacionadas