Cambiar router HGU por neutro

Hola xcarles ,

no tengo ningún equipo con Merlín así que no te puedo decir. De todas maneras el tener habilitado IGMP snooping, según entiendo yo, no debería afectar a que te funcionara o no. Simplemente, el tenerlo deshabilitado haría que tu red (incluída la wifi) se llenase de paquetes multicast. Efectivamente el rendimiento (sobre todo wifi) sería mucho peor pero entiendo que la funcionalidad no debería verse afectada.

Hola,

al final ya lo tengo todo funcionando (no perfectamente eso si) en OpenWRT. Ahora entiendo porque Theliel o aleph20 repiten las mismas cosas una y otra vez 😀, si es que en un A-B-C: DNS, rutas, masquerade

Digo no perfectamente, porque me ocurre una cosa extraña. Algunos poquísimos canales, #Vamos por ejemplo no se llegan a ver bien, demasiado pixeleado y con cortes, como pasa cuando no tienes ancho de banda suficiente. También he visto que otros canales no se cortan pero la calidad no es la que debería ser. Los mismos contenidos en la app de Movistar+ de mi TV se ven mucho mejor (conectada al mismo router). Supongo que tendré algún tema raro en la configuración como un doble NAT o algo del estilo que pueda afectar al rendimiento.

Por cierto, por si sirve de referencia a alguien, tenía dos cosas mal:

1. El proxy IGMP. Lo tenía configurado, pero de forma errónea. Hay que seleccionar un tráfico upstream y un downstream. El dowstream es la lan y era correcto pero en el upstream tenia seleccionada la interfaz PPoE y ahí estaba el error. Cambiado por la interfaz al HGU y todo bien.
2. Luego está el tema archicomentado de hacer masquerade del tráfico que va al HGU. No lo tenía bien configurado con iptables. Que por cierto en OpenWRT se puede hacer en el interfaz gráfico en Firewall->NAT rules.

Por si a alguien le vale, es muy interesante este post que aunque ya viejo, es muy interesante sobre todo la parte de Resolución de problemas. Por ejemplo, no se me había occurido lanzar el demonio IGMP en primer plano, al hacerlo me di cuenta enseguida que estaba mal configurado (no actualizaba rutas), en cuanto lo cambié ya vi como me iba añadiendo más rutas inmediatamente.

Gracias svillar 

Tengo un asus RT-AX88U con fiormw melrlin 386-2_6 y he configurado todos los pasos que indicas, pero hay uno que no me sale:

• Enable efficient multicast forwarding (IGMP Snooping); Enable

tengo esto LAN-->IPTV 

Y los canales y la guía lo veo, pero el menú no va da error de red.

Saludos y gracias

Buenas svillar 

-En lo relativo a las resoluciones DNS, si resuelve, resuelve

-En lo relativo al host main.acs.telefonica.net, hay diferentes "conexiones" que realiza un deco hacia Movistar, pero no significa que todos ellos sean necesario. En cualquier caso creo que estás confundiendo lo que estás viendo ahí. OpenWRT no es el que conecta a dicho dominio, sino el Deco. Las conexiones son punto a punto, con lo que a menos que OpenWRT esté interceptando las conexiones SSL/TLS, da exactamente igual los certificados que tenga o no tenga, es una cuestión exclusiva del Deco con el servidor remoto. La misma analogía sucede cuando un equipo de tu red local accede a cualquier web https, tu Router no tiene nada que decir ahí, a menos que repito esté actuando interceptando el tráfico, que no es el caso. Por otro lado y para cerrar aun más el asunto, el dominio en cuestión no impediría ver la tele, dicho servicio se usa para la gestión remota del Deco. El motivo por el cual la conexión se rechaza es por una de estas dos razones, o las dos:

1º. Efectivamente el Router está interceptando las conexiones e inyectando su propio certificado.

2º. El host en cuestión usa un certificado propio no reconocido universalmente, con lo que si el cliente TR069 del deco aplica una regla estricta sobre ello y no posee internamente el CA que emitió el certificado, abortará la conexión.

-----------

Sin tener el dispositivo delante y poder acceder internamente a él, es imposible saber que pueda estar pasando. Si el Router permite un control adecuado, en principio da igual el que sea, se puede configurar sin problema siempre que cuente con las utilidades/demonios necesarios. Hace ya algún tiempo la verdad que no toco OpenWRT, pero no veo ningún tipo de motivo por el cual no pueda funcionar.

Partiendo de que la conexión PPPoE la establece correctamente, el resto es lo mismo, los tres pasos básicos:

1º. Asignar datos IP a la interfaz WAN a la que se conecta, que sean coincidentes como es natural dentro de la red del HGU, no a la interfaz PPPoE. Esto es necesario para que el tráfico que entra en el HGU, una vez enmascarado, para el HGU vendrá de su propia red local, y el Router propio sabrá también hacia donde enviarlo.

2º. Enmascarar el tráfico que sube, para que el HGU lo vea como tráfico de su propia red

3º. Rutas pertinentes, servidor DNS condicional.

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

Pasos dependiendo de internamente como esté preconfigurado el Router, pero que son habituales causar problemas. Me temo que para poder verificarlos es necesario como he dicho ver y comprobar internamente algunos ajustes y parámetros. Algunas de estas cuestiones pueden ser "automáticas" en el Router que sea o no, y requieren ser especificadas de forma concreta:

4º. Asegurarse de tener habilitado no solo IGMP Snooping, sino IGMP Proxy, sin él, el tráfico Multicast es más que probable que no baje

5º. En la misma línea que lo anterior, el tráfico IGMP debe de tener permitido alcanzar al Router, por defecto el tráfico entrante al Router es filtrado, con lo que se hace necesario asegurarse que fluya bien. Ya sea creando una regla para permitir específicamente IGMP, o incluso para permitir todo el tráfico que venga del HGU

6º. Tener cuidado con el TTL, es otro problema habitual que la mayoría toma como "imposible de diagnosticar". Si un paquete de datos, el que sea, al decrementarlo el dispositivo de red llega a cero, el paquete se descarta. Dependiendo de como nos envíe el servidor de arriba los paquetes de datos, puede ser necesario modificar el TTL. Es algo habitual que suceda, porque de base no está planteado que exista algún salto adicional en la red, y llegan ya con TTL 1, al entrar en el siguiente...

Pues vaya, svillar . La verdad es que nunca he trasteado con OpenWRT así que poco puedo decirte sobre su configuración. De todas formas supongo que será lo de siempre, dnsmasq, iptables, route o ip route..., muy similar a lo que has hecho en el ASUS. Solo me atrevo a sugerir a bote pronto (y a ciegas) algunas minucias que podrías volver a comprobar, por si suena la flauta.

Por lo que cuentas parece claro que el ASUS hace "algo" que la configuración de OpenWRT no replica. (Esto es lo fácil; lo difícil es saber qué ;-). Por si acaso tuviera algún efecto raro decirte que sospecho que la ruta 172.26.0.0/17 no abarca todas las rutas para IPTV que tiene el HGU. En mi Mitrastar quedan fuera dos: 10.128.0.0/9 y 172.23.96.0/21, máscaras 255.128.0.0 y 255.255.248.0 ("Device Info --> Route"). No sé si esto es muy importante y además es raro que el ASUS funcione sin ellas y el OWRT no, pero nunca se sabe y podría arreglar problemas que se presenten más adelante.

Yo comprobaría también la configuración DNS de OWRT, no vaya a ser que haga cosas "avanzadas" y le de por filtrar las conexiones al puerto 53 y reemplazarlas por sus propios DNS (Asus-Merlin tiene una opción llamada DNSFilter que hace precisamente eso y que en tiempos me causo problemas con el servidor DNS condicional de IPTV). Ya que estamos no me queda claro si tienes activo dicho servidor condicional (¿dnsmasq.conf?); en tal caso puedes probar que el deco lo reciba, junto con la opción 240, por DHCP.

También repasaría la tabla "nat" de iptables, en particular la cadena POSTROUTING, y las cadenas INPUT y FORWARD de la tabla "filter". Algo así como:

iptables -t nat -L POSTROUTING -v

Y algo "Off Topic" para terminar. Tenías razón, en el ASUS (no sé si con OWRT) no hace falta crear manualmente una regla que enmascare el tráfico que sube por wan_iface para que el deco funcione, ¡ya lo hace el propio ASUS!, cosa que yo no había comprobado hasta que tú lo mencionaste.

Y ya sabes: siempre nos quedará Theliel .

Suerte con los bichos

Hola de nuevo,

después de tener todo funcionando con el ASUS procedí a migrar el setup a un tp-link que tengo con OpenWRT. Replicar la configuración fue bastante sencillo y cosas que en el ASUS no podía hacer, como DNS condicional son sencillas en OpenWRT.

El caso es que aún cuando el setup es en principio el mismo, la TV no me funcionaba. Revisé lo típico de hacer MASQUERADE, los DNS, las rutas 172.x.x.x etc.. pero todo parecía estar en regla. Las tablas de enrutamiento son idénticas en el ASUS y el OpenWRT. Podría haber temas de firewall ya que ahí es dificil de comparar, no se decirlo. Ya desesperado traté de descartar algún tema en el deco. Lo que hice fue lo siguiente:

1. montar el ASUS de nuevo y conectar el Deco, todo va perfectamente.
2. el ASUS y el otro router tienen configurada la misma LAN y el deco una IP estatica de esa LAN (para esta prueba, no es el setup definitivo)
3. "en caliente" cambio los cables del HGU y del deco del ASUS al router con OpenWRT 

Entonces para mi sorpresa todo funciona. Luego si reinicio todos los equipos vuelve a fallar, pero el caso es que si me conecto incialmente con el ASUS y luego cambio al OpenWRT de alguna manera funcionan las cosas.

Ideas que se me ocurren:

1. El DNS está mal en OpenWRT y no resuelve bien. El deco ya hizo la resolución mientras estaba conectado al ASUS y luego simplemente usa la cache con lo cual no importa que no tenga acceso a los DNS internos. Suena plausible, pero comandos como dig @172.26.23.3 google.com funcionan perfectamente para cualquier equipo conectado al OpenWRT.
2. Algún tema de seguridad. En concreto lo que hice fue inspeccionar el trafico del deco mientras estaba conectado al OpenWRT con wireshark y cuando se intenta conectar a main.acs.telefonica.net obtengo un error de TLS1.2 de certificado inválido. Se me ocurren dos cosas, una que el OpenWRT tiene CAs antiguos (improbable estoy usando una version reciente) o 2 el ASUS es más laxo con las comprobaciones y admite el certificado como valido. De todas maneras no se si la conexion a ese equipo es importante.
3. Alguna otra mala configuración y que el deco sea capaz de mantener las conexiones abiertas a pesar del cambio de cables?

Alguna idea Theliel o aleph20 ?

Hola aleph20 

gracias por los comentarios, son siempre bien recibidos. Te respondo a cada una de las cosas que comentas:

1) Ese valor de la OPCH me da que lo tiene preestablecido el deco porque ya me lo tiene fijado así.

2) El deco efectivamente me funciona conectado al ASUS directamente. A mi también me extrañó que no tuviera que hacerle nada, no se si como dices el IGMP proxy ya lo resuelve. En cualquier caso gracias por el comentario porque me servirá para la configuración con OpenWRT que aún no la tengo funcionando.

3) Tienes toda la razón está mal, pero efectivamente fue una errata. La configuración que tengo es 255.255.128.0 en efecto.

Hola svillar .

Me alegro de que hayas conseguido lo que querías. Viendo la solución que propones se me ocurren tres comentarios (un poco paranoicos, no hagas mucho caso si todo te funciona):

1) En la configuración del deco fijas, correctamente, el DNS 172.26.23.3. Podrías también rellenar la "Dir. IP del OPCH" (es el servidor de Imagenio) con el valor (creo, en todo caso es la "Option 240") 239.0.2.29:22222. No sé si es absolutamente necesario pero podría ayudar.

2) ¿Te funciona el deco conectado al ASUS sin enmascarar el tráfico que sube al HGU? Es posible que con IGMP Proxy sea suficiente pero si no es así necesitarás definir la correspondiente regla de "iptables". El problema es que no sé si esto se puede hacer con el firmware de fábrica sin usar Merlin, así que ojalá que no lo necesites.

3) Seguramente sólo es una errata (y si es así no me hagas caso) pero la ruta que defines para la red 172.26.0.0 con máscara 255.128.0.0, es decir, la red 172.26.0.0/9 (que por cierto es la misma que 172.0.0.0/9) tiene un problema: parte de las direcciones que abarca son públicas, es decir, asignables en la internet global, lo que alguna rara vez podría dar problemas. (En el rango 128/8 las únicas direcciones privadas son 172.16.0.0/12). Si no es una errata puedes cambiar la máscara por 255.255.128.0 o incluso, mejor que sobre que no que falte, usar toda la red privada: host 172.16.0.0, mask 255.240.0.0 (a condición, claro, de no usar estas IPs en tu red local).

Saludos

Muchas gracias, probaré, pues tengo esos mismos aparatos, y tulimamente tengo problemas con el deco que se queda colgado, solo funciona correcto sin semibridge ni monopuesto, con lo cual el asus no sirve para nada pues quien lo lleva todo es el HGU. Y lo que busco es que funcione bien el deco en monopuesto, a ver si con tu config me funciona

Gracias

Un saludo

Ahora lo que me queda es replicar esta configuración con OpenWRT. Lo necesito por un tema de VLANs así que tengo más trabajo por delante 😀. En cuanto lo consiga seguramente publicaré mis conclusiones en otro hilo por referencia.

Tras la inestimable ayuda de aleph20 y sobre todo Theliel podemos dar el hilo por cerrado y resuelto.