Reiniciado el decodificador de IPTV y YA NO VA!

Buenos días @IgnacioHR,

Comprobamos que has aceptado la solución del caso y te lo agradecemos. Nos alegramos de que tras la información aportada quede resuelto. Procedemos por lo tanto al cierre del caso.

Recordarte que permanecemos a tu disposición en este foro ante cualquier consulta, no dudes en retomar el contacto si necesitas de nuestra ayuda y estaremos encantados de atenderte. 

Muchas gracias, que tengas un buen día, un saludo

Irene

Hola IgnacioHR

Nos alegra que lo hayas podido solucionar y te agradecemos la información de como lo has solucionado, porque seguro que será útil para otros usuarios.

Por otra parte, si consideras que tu consulta está resuelta, te agradeceríamos que en el hilo que has abierto, pulsases en el botón “Aceptar como solución” del post en el que se te ha resuelto tu caso. Es importante para nosotros que vuestras consultas queden resueltas y para otros usuarios es útil utilizar estas respuestas para sus dudas.

Un saludo.

Nacho.

Buenas IgnacioHR 

Revisando todo lo expuesto, por un lado veo un problema potencian en las rutas que tienes creadas, ya sea por problema de configuración de bird o por donde están llegando.

Por un lado tenemos la interfaz ppp0 que doy por sentado que es la interfaz virtual que levanta el cliente PPPoE. Esta es la interfaz que se debería de usar para el 100% del tráfico que va destinado a Internet.

PERO, por otro lado tenemos lo que tu Router la llama la interfaz WAN, que sería realmente la interfaz física. Muchas veces uno se puede confundir tomándolas como iguales, y en nada lo son. Es cierto que la interfaz virtual PPPoE es sobre la interfaz WAN (El puerto Ethernet físico WAN), pero realmente son interfaces diferentes.

Es decir... que si queremos salir a Internet, usamos ppp0, PERO SI QUEREMOS subir tráfico a la red del HGU, tenemos que usar WAN. Teniendo en esto en cuenta, mira tus rutas, y dime si ves algo raro. Todas las rutas relativas a IPTV/VoIP es tráfico que debe de subirse al HGU para que a su vez pueda enviarlo a la red privada de Movistar, NO INTERNET, y en cambio todas tienen configuradas ppp0.

Esto, dependiendo internamente como el Router interprete las interfaces vs puertas de enlace, puede ser un problema.

-------------------

Mas cosas:

Cuando haces uso de ip mroute, ves el problema. Sí, llega tráfico Multicast a WAN, pero este no lo está pasando al bridge/LAN. Lo vemos porque te escupe rápidamente la IP del HGU, y no 0.0.0.0

-------------

IGMP Proxy es necesario, porque lo que se pretende es pasar el tráfico Multicast de WAN a LAN... esta es precisamente la función de IGMP Proxy. Como con todo requiere configuración. En este caso es simple, pero es imposible poner ningún tipo de configuración sin saber que demonio se está usando, que interfaces...  el clásico y bueno igmp-proxy sería algo como:

quickleave
phyint wan upstream
altnet 172.16.0.0/12;
phyint br0 downstream

Pero te repito que esto varía enormemente en función que demonio se esté usando, lo esencial es siempre lo mismo, la interfaz wan en tu caso como upstream, la interfaz lan/br como downstrean, la red o redes de las que se va a permitir el tráfico Multicast.. algunos demonios se les configura también directamente igmp snooping, otros van a parte.

Y por supuesto, obviamente, una regla en iptables para permitir todo el tráfico multicast de arriba:

iptables -A FORWARD -d 224.0.0.0/4 -p udp -j ACCEPT

Hola

Veo dónde está el problema, pero no doy con la solución, probablemente por falta de capacidad para interpretar lo que veo. Os cuento lo que veo a ver si veo la luz o alguien la ve y me puede decir algo.

explorar lo que pasa en la wan

tcpdump -nn -i {wan} host 239.0.2.30

Esto muestra tráfico saliente para unirse al grupo multicast Y muestra tráfico UDP que proviene de 172.26.20.39 hacia 239.0.2.30 Hay mucho tráfico, lo que parece normal y viene de movistar.

explorar lo que pasa en la lan

tcpdump -nn -i {lan} host 239.0.2.30

Esto muestra lo que creo que son solicitudes para unirse al grupo multicast. Pero NO se ve tráfico udp entrante desde la wan.

Mi conclusión es que por alguna razón ese tráfico no pasa desde la wan a la lan y debería pasar.

'ip mroute' para las direcciones que estoy filtrando muestra esto:

root@jo-con-el:/tmp# ip mroute | grep 239.0.2.30
(192.168.3.1,239.0.2.30)         Iif: eth0       Oifs: br-lan  State: resolved
(192.168.3.2,239.0.2.30)         Iif: unresolved  State: unresolved

Nota,

la 192.168.3.1 es la IP del HGU

la 192.168.3.2 es la IP de la WAN del router.

la 192.168.1.2 es la IP de la LAN del router. (no se muestra en el ejemplo)

la 192.168.1.70 (que no se muestra en este mensaje) es la IP del deco que está en la LAN

He probado con igmpproxy y con omcproxy, los resultados son los mismos. Con mcproxy no he sido capaz de llegar al mismo resultado. En un momento dado, teniendo, por error, activado omcproxy y igmpproxy recién instalado, el tráfico UDP apareció por la LAN y el deco "resucitó" pero no aguantó un reinicio y no es buena idea tener dos servicios que hacen lo mismo.

No se dónde puede estar el problema. He activado logs en el firewall y no se está rechazando nada, lo cual indica que podría ser un problema de las rutas multicast. Pero como he dicho antes, me pierdo un poco interpretando lo que veo.

Sigo...

Buenas IgnacioHR 

Es así como funciona el tráfico Multicast, un dispositivo solicita la "unión" a un grupo multicast, y el Router automáticamente le da acceso a dicho stream. No hace nada más porque ese stream es el primero, es el de configuración, el inicial, si el Deco no se une a él pues obviamente el deco se queda "muerto".

Motivo? Pues no hay muchas opciones: y muy facil de comprobar simplemente pinchándolo tal como lo tenías todo antes y mirando el tráfico Multicast e IGMP que llega al Router:

Si el router recibe el paquete IGMP de unión, y responde bien con el tráfico Multicast, es problema del Switch. Si el Router no recibe siquiera el paquete IGMP, es el Switch. Si el Router recibe el paquete IGMP pero no devuelve el tráfico Multicast, es el Router.

El Switch puede estar bloqueando Multicast/IGMP, revisar ajustes del Switch relativos a

El Router puede no tener habilitado IGMP Proxy, y por ende no bajar el tráfico Multicast. También podría no tener configurada las rutas necesarias, un fallo del bird o cualquier otra cosilla. O el Router podría estar bloqueando directamente el tráfico Multicast a bajo nivel.

Ayer continué con las pruebas. Activando el DHCP en el HGU el DECO se inicializa correctamente. He grabado la inicialización con wireshark en un fichero aparte usando un switch intermedio y conectando una tarjeta de red sin inicializar para no introducir elementos que filtrar. Mi conclusión es que el DECO envía un paquete:

192.168.3.200 239.0.2.30 IGMPv2 60 Membership Report group 239.0.2.30

y a continuación se recibe tráfico UDP como respuesta a esa solicitud.

Sin embargo, cuando se conecta el deco en la lan del OpenWRT, ese tráfico no llega a la lan. Como el HGU está en modo half bridge, sospecho que el paquete que se envía desde la LAN a la 239.0.2.30 se está enviando a internet (ruta por defecto que es la para del ppp) en vez de enviarse a la ip del HGU y que sea éste el que la envíe al servidor de imagenio. Espero tener un rato esta tarde para probar.

Buenas IgnacioHR 

"Lo cual, como puedes entender, los clientes aceptamos siempre y cuando no perdamos el servicio o seamos notificados de alguna forma con tiempo para adaptarnos al cambio."

Obviamente no tienen que avisar absolutamente de nada. El uso de equipos propios aunque se permite, no implica que el ISP tenga que dar ningún tipo de información al respecto. El ISP te da los dispositivos para tener el servicio tal cual lo contratas. Lo hemos dicho multitud de veces, y yo soy el primero que uso mis propios dispositivos, pero quien lo hace asume las consecuencias de ello.

Respecto a conectarlo al HGU, que esté en medio-bridge no implica que tenga deshabilitado DHCP, si lo tienes deshabilitado es porque lo habrás deshabilitado tu. De echo no es algo que recomiende, máxime la mayoría de usuarios lo tienen conectado al HGU. Obviamente no hacía falta comprobarlo si tenías en el HGU DHCP deshabilitado, lo conectases o no conectases no iba a funcionar. Lo cual ten cuidado porque no sé que otros cambios hayas podido realizar en el HGU que puedan afectarte igualmente (para probar). O te verás obligado ha realizar un reset.

------

Dices que después del intento al servidor TR069 no ves mucho más, pero dices que sí ves tráfico Multicast. Ten en cuenta que Movistar usa el tráfico Multicast tanto para actualizar los Deco, gestión/control y muchas otras cosas. También es por donde recibe la guía, lista de canales, bla bla bla. Dicho de otro modo, que el tráfico Multicast que se envía por la interfaz de IPTV no solo es la retransmisión del contenido, por ahí circula el 95%, excluyendo algo de tráfico unicast convencional. La secuencia de arranque suele ser la misma:

Primero accede al stream de configuración, y de existir una actualización empieza a descargarla/instalarla. Una vez ha recibido todo el stream de configuración pasa al stream de las demarcaciones, y luego al de canales y después DRM. En medio de todo ello posiblemente ya haya intentado conectar una o varias veces a TR069.

Es más, dado que soy muy quisquilloso con las llamadas a casa, mantengo mi propio servidor DNS y mi propia lista negra donde voy añadiendo todo aquel dominio que no requiero, y el susodicho dominio lo tengo directamente bloqueado. Es decir, que en mi caso es que ni siquiera se inicia un intento de conexión.

Es cierto que ahora mismo tenemos un parqué con varios HGUs y varios deco, y no siempre todo es aplicable a todo. Es decir, que yo puedo estar al 100% seguro de ciertas cuestiones pero en lo tocante a mis propios dispositivos. Digo esto porque... podría pasar que algún deco de Movistar internamente mostrase dicho comportamiento? Pues hombre... por poder puede, pero sería muy rebuscado.

De todos modos es más simple curarse en salud, conectado al HGU en su modo nominal a ver si funciona. Simple. Y ya te digo que es mucho mejor controlar el tráfico desde el propio Switch, te quitas mucha [....] y te quedas realmente con lo que te importa

Acabo de hacer unas pruebas. Voy con los resultados.

> Movistar puede modificar en cualquier momento cualquier parámetro o peculiaridad que puede dejarte KO tu anterior estructura. 

Lo cual, como puedes entender, los clientes aceptamos siempre y cuando no perdamos el servicio o seamos notificados de alguna forma con tiempo para adaptarnos al cambio.

> Mi opinión? Que en algún punto de tu red estás metiendo la pata.

Esto es obvio. Si no estuviera metiendo la pata no tendría este problema y no estaría pidiendo ayuda para solucionarlo. La cuestión no es que yo no "sea perfecto" sino ayudarnos a saber cómo debemos adaptarnos a los cambios o qué es lo que puede no estar bien.

> no hace falta recordar la obligatoriedad de IGMP Snooping en el Switch...

Todo esto es correcto, pero por ahora creo que no viene al caso. Mi problema está incluso antes de que el deco me muestre la página para seleccionar el canal que quiero ver. Veo tráfico multicast y de suscripciones a canales (está en la captura de pantalla hecha con wireshark), pero no los he comentado porque ahora serían una distracción del problema principal. El DECO no arranca y no me permite seleccionar ningún canal. No veo la parrilla ni intenta obtenerla.

> Seguramente tienes problema con alguna ruta si tienes el esquema mencionado anteriormente.

Tengo "bird" instalado y configurado en el OpenWRT, y veo las rutas que recibo por RIP correctamente configuradas. 

Active IPv4-Routes

Network Target IPv4 gateway Metric Table Protocol

He cambiado algunos números por letras para no "dar pistas" a los curiosos.

Dicho esto, insisto, que el problema es que el DECO NO intenta conectar con ningún otro servidor y se queda en el punto anterior después de la conexión fallida con el servidor del TR069. Si viese un intento de conexión con algún servidor para obtener la parrilla o algo podría seguirle la pista con el wireshark, pero da la sensación de que todo termina con la conexión tls rechazada y el deco se queda paralizado.

> Puedes probar a conectar directamente el Deco al HGU si está en medio-bridge tendría que funcionar igualmente

Lo he probado, pero, como pensaba, no funciona y se queda la pantalla en rojo. El problema es que cuando el HGU está en modo bridge, y el deco se conecta a un puerto libre del HGU, no hay un DHCP que proporcione configuración alguna al DECO. Lo que el usuario ve (yo) es una pantalla roja. Lo tengo grabado en vídeo si alguien tiene curiosidad. Voy a probar habilitando el servicio de DHCP del HGU y luego vuelvo con más resultados.

> Quizás peticiones DNS que se te escapan?

Eso se vería en el wireshark, al igual que se ve la solicitud al DNS para resolver la IP del servicio del TR069. He verificado que el DNS que se manda por DHCP al deco es el 172.26.23.3 que entiendo que es el que resuelve los nombres para el servicio de IPTV.

Sigo investigando, en un rato comento los resultados.

Gracias.

Ignacio

Buenas IgnacioHR 

Por eso te decía, imaginando algo así, que lo primero que tienes que probar es en el escenario base, es decir, HGU en modo nominal y Deco conectado directamente por cable a él sin Switch en medio. Eso es necesario para poder empezar a hablar.

Por qué? Pues por lo que he dicho siempre, Movistar puede modificar en cualquier momento cualquier parámetro o peculiaridad que puede dejarte KO tu anterior estructura. De echo ha pasado más de una vez... ya no porque hayan realizado grandes cambios (algunos han hecho), sino por como cada cual lo ha configurado/implementado en su red.

En lo relativo al dominio ACS, es el servidor de "control" TR069, posiblemente esté fallando dicha conexión por certificado caducado en la firmware del Deco o el servidor TR069, no es algo demasiado raro, pero en cualquier caso esto no debería de "parar" el funcionamiento del deco. Piensa una cosa simple, el deco que tengas lo tiene instalado multitud de usuarios, si un problema de ese calibre apareciese, serían cientos/miles afectados. Uno podría pensar que entonces quizás tu Deco no se ha actualizado, pero volveríamos a lo mismo, si toda tu red está bien configurada, se podría actualizar sin problema alguno.

--------------------

Mi opinión? Que en algún punto de tu red estás metiendo la pata. Dices que este va conectado a un Switch, y el Switch a un OpenWRT casero, y este imagino al HGU.

En tal caso, no hace falta recordar la obligatoriedad de IGMP Snooping en el Switch, ni los por mayores/menores de la configuración requerida en el Router principal para subir el tráfico IPTV hacia arriba.

Seguramente tienes problema con alguna ruta si tienes el esquema mencionado anteriormente. Puedes probar a conectar directamente el Deco al HGU si está en medio-bridge tendría que funcionar igualmente (menos Netflix y algunos canales donde el DRM va por otro lado)

Si funciona, que posiblemente funcione, asistirte más es complicado sin tener acceso a la red. Quizás peticiones DNS que se te escapan? Quizás alguna ruta?

Captura el tráfico mucho mejor en el Switch, porque este si te va a decir realmente todo lo que sale/entra del deco, si capturas en el Router puedes desde liarte con la interfaz donde escuchas a no poder ver tráfico que a lo mejor está el Switch cortando o no está haciendo circular bien (IGMP por ejemplo)