Autor Tema: [Tutorial] Movistar FTTH con OpenWrt (VOIP e Imagenio) (Leído 877581 veces)

astrak · « **Respuesta #360 en:** 13-05-2014, 10:39 (Martes) »

Cita de: Noltari en 13-05-2014, 01:21 (Martes)

Buenas,

He actualizado el script, aunque no sé si detectará todo bien.
Ahora debería funcionar para todos los routers con switch rtl8366 que tienen el puerto WAN en la interfaz eth1, en vez de en eth0 como si fuera un puerto más del mismo switch.
movistar_r8.sh
movistar_r8.txt

Espero tu feedback y entiende que podría no funcionar.
Si haces pruebas y no funciona ni internet habiendo seleccionado Imagenio y/o VOIP, intenta configurar sólo internet, a ver si así funciona.

Saludos.

Si me da tiempo a llegar a casa antes que el tecnico lo pruebo primero antes de que me pongan la tele y si no despues le hago todas las pruebas.
Si no funciona no problem, no es facil programar a ciegas. Lo que tengo claro es que acabara funcionando.

Un Saludo!

Morax · « **Respuesta #361 en:** 13-05-2014, 13:19 (Martes) »

Hola de nuevo! Vuelvo a escribir por aquí para agradecer nuevamente el trabajo que hacéis.

También para dejar algo de feedback sobre el nuevo script (he probado la v7, no la

para el router WDR4300 con el firmware de la primera página. El Imagenio e internet por cable funcionan de lujo (configuración de imagenio antigua). Sin embargo, el wifi se queda tostado, y es imposible acceder con ningún dispositivo.

He usado el script 7 desactivando tanto tv como vozip y el wifi vuelve a funcionar perfectamente. Parece un conflicto entre tv-wifi.

He vuelto a la versión 6 del script con tv y funciona tanto imagenio como wifi. Sin embargo, en la versión 6 la tv se congela a veces pasado un tiempo. Si cambio de canal vuelve a verse durante un periodo de tiempo muy corto hasta volver a congelarse.

Para resumir:

v6:
- TV: Se ve bien durante un periodo de tiempo hasta que se congela (tengo que probar más ésto)
- Internet cable: Perfecto
- Wifi: Perfecto

v7:
- TV: Perfecto (tengo que probar más ésto)
- Internet cable: Perfecto
- Wifi: Imposible conectar ningún dispositivo.

Muchas gracias de nuevo y seguid así!.

Noltari · « **Respuesta #362 en:** 13-05-2014, 13:41 (Martes) »

Cita de: Morax en 13-05-2014, 13:19 (Martes)

Hola de nuevo! Vuelvo a escribir por aquí para agradecer nuevamente el trabajo que hacéis.

También para dejar algo de feedback sobre el nuevo script (he probado la v7, no la para el router WDR4300 con el firmware de la primera página. El Imagenio e internet por cable funcionan de lujo (configuración de imagenio antigua). Sin embargo, el wifi se queda tostado, y es imposible acceder con ningún dispositivo.

He usado el script 7 desactivando tanto tv como vozip y el wifi vuelve a funcionar perfectamente. Parece un conflicto entre tv-wifi.

He vuelto a la versión 6 del script con tv y funciona tanto imagenio como wifi. Sin embargo, en la versión 6 la tv se congela a veces pasado un tiempo. Si cambio de canal vuelve a verse durante un periodo de tiempo muy corto hasta volver a congelarse.

Para resumir:

v6:
- TV: Se ve bien durante un periodo de tiempo hasta que se congela (tengo que probar más ésto)
- Internet cable: Perfecto
- Wifi: Perfecto

v7:
- TV: Perfecto (tengo que probar más ésto)
- Internet cable: Perfecto
- Wifi: Imposible conectar ningún dispositivo.

Muchas gracias de nuevo y seguid así!.

¿Tienes instalado kmod-bridge?
Si no lo tienes instalado no hay igmp-snooping y de ahí viene el fallo.

P.D: al ser un módulo del kernel no vale con haberlo instalado en el firmware con opkg, sino que tendría que haberse seleccionado en el momento de compilar el firmware.

Saludos.

Morax · « **Respuesta #363 en:** 13-05-2014, 16:24 (Martes) »

Hola Noltari. Lo tengo instalado. Venía instalado en el firmware que has puesto en la primera página, no? Es el que tengo puesto para el wdr4300. Si me voy a software desde luci lo veo instalado.

Un saludo!

arrobar · « **Respuesta #364 en:** 13-05-2014, 21:42 (Martes) »

Hola a todos, lo primero es dar las gracias a Noltari por este estupendo manual.. Soy mucho de romperme la cabeza hasta que consigo sacar las cosas, pero creo que después de 2 días voy a desistir y voy a pedir vuestra ayuda.

Tengo un tplink wr1043nd y le he instalado OPENWRT para sustituir el Comtrend (menudo bicharraco de grande) que me ha dado movistar. El caso es que después de muchas pruebas (pero muchas de verdad,

) al fin he conseguido tener internet y tv cargando el script de Noltari, pero haciendo algunos cambios. Internet no me funcionaba si no añadía la siguiente línea a la configuración del switch:

config switch
   option reset '1'
   option enable_vlan '1'
   option name 'rtl8366rb'
   option enable_vlan4k '1'

Con esta línea ya me funciona internet y la tele, pero el caso es que no hay forma de acceder a los menús de la tv (aunque la guía sí funciona)

He tenido instaladas las versiones de Openwrt Attitude Adjustment 12.09 y ahora tengo OpenWrt Barrier Breaker y sigo sin poder ver los menús, a alguien se le ocurre algo? Seguramente sea una tontería, pero no encuentro la forma de que funcione.

Un Saludo y gracias de antemano

astrak · « **Respuesta #365 en:** 13-05-2014, 22:12 (Martes) »

Cita de: Noltari en 13-05-2014, 01:21 (Martes)

Buenas,

He actualizado el script, aunque no sé si detectará todo bien.
Ahora debería funcionar para todos los routers con switch rtl8366 que tienen el puerto WAN en la interfaz eth1, en vez de en eth0 como si fuera un puerto más del mismo switch.
movistar_r8.sh
movistar_r8.txt

Espero tu feedback y entiende que podría no funcionar.
Si haces pruebas y no funciona ni internet habiendo seleccionado Imagenio y/o VOIP, intenta configurar sólo internet, a ver si así funciona.

Saludos.

Pues despues de ganarme el premio a ****** del año con bastante ventaja sobre el segundo por estar 2 horas haciendo pruebas con la ONT apagada y extrañandome de que nada conectara, parece que todo funciona OK. Tanto internet, como imagenio, con la guia y los menus funcionan. Seguire haciendo pruebas, todavia ni he activado la wifi ni nada...

Noltari, definitivamente eres un crack!!

Saludos y muchas gracias a todos!

Noltari · « **Respuesta #366 en:** 13-05-2014, 22:18 (Martes) »

Cita de: arrobar en 13-05-2014, 21:42 (Martes)

Hola a todos, lo primero es dar las gracias a Noltari por este estupendo manual.. Soy mucho de romperme la cabeza hasta que consigo sacar las cosas, pero creo que después de 2 días voy a desistir y voy a pedir vuestra ayuda.

Tengo un tplink wr1043nd y le he instalado OPENWRT para sustituir el Comtrend (menudo bicharraco de grande) que me ha dado movistar. El caso es que después de muchas pruebas (pero muchas de verdad, ) al fin he conseguido tener internet y tv cargando el script de Noltari, pero haciendo algunos cambios. Internet no me funcionaba si no añadía la siguiente línea a la configuración del switch:

config switch
   option reset '1'
   option enable_vlan '1'
   option name 'rtl8366rb'
   option enable_vlan4k '1'

Con esta línea ya me funciona internet y la tele, pero el caso es que no hay forma de acceder a los menús de la tv (aunque la guía sí funciona)

He tenido instaladas las versiones de Openwrt Attitude Adjustment 12.09 y ahora tengo OpenWrt Barrier Breaker y sigo sin poder ver los menús, a alguien se le ocurre algo? Seguramente sea una tontería, pero no encuentro la forma de que funcione.

Un Saludo y gracias de antemano

Necesito que aportes más datos: ¿Configuración nueva o antigua (supongo que nueva)? ¿Qué imagen estás usando? ¿La has compilado tú? ¿Estás usando igmpproxy o mcproxy? ¿Qué versión del script estás utilizando?

Saludos.

Cita de: astrak en 13-05-2014, 22:12 (Martes)

Pues despues de ganarme el premio a ****** del año con bastante ventaja sobre el segundo por estar 2 horas haciendo pruebas con la ONT apagada y extrañandome de que nada conectara, parece que todo funciona OK. Tanto internet, como imagenio, con la guia y los menus funcionan. Seguire haciendo pruebas, todavia ni he activado la wifi ni nada...

Noltari, definitivamente eres un crack!!

Saludos y muchas gracias a todos!

Muchas gracias por el feedback. La subo al primer post

.

Saludos.

arrobar · « **Respuesta #367 en:** 14-05-2014, 00:24 (Miércoles) »

Cita de: Noltari en 13-05-2014, 22:18 (Martes)

Cita de: arrobar en 13-05-2014, 21:42 (Martes)
Hola a todos, lo primero es dar las gracias a Noltari por este estupendo manual.. Soy mucho de romperme la cabeza hasta que consigo sacar las cosas, pero creo que después de 2 días voy a desistir y voy a pedir vuestra ayuda.

Tengo un tplink wr1043nd y le he instalado OPENWRT para sustituir el Comtrend (menudo bicharraco de grande) que me ha dado movistar. El caso es que después de muchas pruebas (pero muchas de verdad, ) al fin he conseguido tener internet y tv cargando el script de Noltari, pero haciendo algunos cambios. Internet no me funcionaba si no añadía la siguiente línea a la configuración del switch:

config switch
   option reset '1'
   option enable_vlan '1'
   option name 'rtl8366rb'
   option enable_vlan4k '1'

Con esta línea ya me funciona internet y la tele, pero el caso es que no hay forma de acceder a los menús de la tv (aunque la guía sí funciona)

He tenido instaladas las versiones de Openwrt Attitude Adjustment 12.09 y ahora tengo OpenWrt Barrier Breaker y sigo sin poder ver los menús, a alguien se le ocurre algo? Seguramente sea una tontería, pero no encuentro la forma de que funcione.

Un Saludo y gracias de antemano
Necesito que aportes más datos: ¿Configuración nueva o antigua (supongo que nueva)? ¿Qué imagen estás usando? ¿La has compilado tú? ¿Estás usando igmpproxy o mcproxy? ¿Qué versión del script estás utilizando?

Saludos.

Ok te cuento, configuración nueva.
La imagen me la he descargado de la web de openwrt:
http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin (trunk)

Tengo instalado igmpproxy y la versión del script es la 7 (probé con la 8 pero también hace lo mismo)

Un Saludo y gracias

Morax · « **Respuesta #368 en:** 14-05-2014, 02:02 (Miércoles) »

He estado probando cositas.

El wifi no funciona con firmware de la primera página y el script v7-8. He probado con otra imagen diferente y funciona bien todo, incluido el wifi.

Ahora bien, también he encontrado que el Upnp queda capado después de aplicar la configuración de los scripts 7-8.

Estos son los errores que he detectado en mi escenario (imagenio antiguo,wdr4300)
v6:
- Todo Ok menos tv, a la hora o así se corta.

v7-8:
- Todo Ok pero me capa el Upnp.

ACTUALIZO:
He dejado probando esta noche el imagenio y cuando me levanto lo mismo con el script v8: imagen congelada. ¿De verdad a nadie le ocurre ésto? Me pasaba tanto con el Comtrend como ahora con el WDR 4300.
Un saludo!

Pteridium · « **Respuesta #369 en:** 14-05-2014, 10:54 (Miércoles) »

Cita de: Morax en 14-05-2014, 02:02 (Miércoles)

He estado probando cositas.

El wifi no funciona con firmware de la primera página y el script v7-8. He probado con otra imagen diferente y funciona bien todo, incluido el wifi.

Ahora bien, también he encontrado que el Upnp queda capado después de aplicar la configuración de los scripts 7-8.

Estos son los errores que he detectado en mi escenario (imagenio antiguo,wdr4300)
v6:
- Todo Ok menos tv, a la hora o así se corta.

v7-8:
- Todo Ok pero me capa el Upnp.

ACTUALIZO:
He dejado probando esta noche el imagenio y cuando me levanto lo mismo con el script v8: imagen congelada. ¿De verdad a nadie le ocurre ésto? Me pasaba tanto con el Comtrend como ahora con el WDR 4300.
Un saludo!

Si ya te pasaba con el Comtrend además de con el TP-Link, ¿no podría ser algún problema con el resto de la instalación de fibra, con el deco o con algún otro dispositivo que se conecte por wifi o cable al router (un PC, smartphone o alguna otra cosa con un virus que sature el router? Quizá debas echar un ojo a ver qué te suelta Wireshark.

Off topic 1: ¿de verdad necesitas upnp? Todo lo que he leído sobre él es que puede no ser seguro a peasr de ser útil.
Off topic 2: Desde que jogo metió el parche para el BCM6368/9 ya no hay problemas cuando está SMP habilitado.

Morax · « **Respuesta #370 en:** 14-05-2014, 11:26 (Miércoles) »

Hola Pteridium!

Como dices, me he planteado que sea de mi instalación, pero con comtrend y firmware de telefónica me va perfecto imagenio, tanto en el deco como en PC vía VLC. Además, el imagenio se me cortó anoche cuando no tenía nada encendido. Voy a seguir probando pero me ocurre lo que a otros usuarios, se pixela y se corta, y ahora estoy viendo que ni pasada una hora, es a los pocos segundos también.

Sobre el Upnp sí lo necesito. Es posible que no sea seguro, pero es la única manera que tengo de poder tener dos consolas que usan los mismos puertos para funcionar, además que algunos otros servicios para conectarme desde fuera me obligan a tenerlo...

Estoy usando la versión de la página principal para WDR4300 junto con el router v1.7 de hardware. Probando tanto v8 del script como v6 que es la que no me capa el wifi.

Colerax · « **Respuesta #371 en:** 14-05-2014, 19:20 (Miércoles) »

Yo tengo el WDR4300 con el firmware del primer post, al aplicar el script (R7), el UPNP no funciona (deniega todas las solicitudes), reinstalando el paquete miniupnpd y volviendolo a activar se soluciona, y vuelve a funcionar el UPNP (al menos en mi caso)

Noltari · « **Respuesta #372 en:** 15-05-2014, 15:32 (Jueves) »

Cita de: Colerax en 14-05-2014, 19:20 (Miércoles)

Yo tengo el WDR4300 con el firmware del primer post, al aplicar el script (R7), el UPNP no funciona (deniega todas las solicitudes), reinstalando el paquete miniupnpd y volviendolo a activar se soluciona, y vuelve a funcionar el UPNP (al menos en mi caso)

Buenas,

Estoy investigando el problema del UPNP, aunque a priori parece deberse a la regla establecida para el videoclub en las configuraciones nuevas de Imagenio.
Personalmente, mi configuración es la antigua así que si alguien con la configuración nueva y conocimientos de redes pudiera investigarlo y/o ofrecer soluciones sería de gran ayuda.

Saludos.

Noltari · « **Respuesta #373 en:** 17-05-2014, 23:09 (Sábado) »

Añadida la versión r9 al primer post.

Cita de: jfm en 27-04-2014, 21:55 (Domingo)

¡Hola todos! mucho tiempo sin pasar por aquí, demasiado trabajo (y tal como están las cosas, que no falte).

Noltari, ¡¡muchas gracias!! magnífico trabajo con las configuraciones y los scripts.

Justo antes de Semana Santa me cambiaron el imagenio a la nueva configuración No ejecuté el script, sino que le eché un vistazo y edité la configuración a mano, porque tenía algunos cambios y quería evitar riesgos. Pero no me funcionó. Entre el trabajo y que cualquier prueba tenía que hacerla cuando ya nadie viera la TV en casa (o sea, de madrugada) tardé en darme cuenta de que la culpa era mía. Uno de mis experimentos interfería con la nueva configuración. Una vez descubierto, todo listo... más o menos.

Resulta que tengo un par de decos (multiroom) por los que pago religiosamente y con la solución disponible sólo puedo ver el videoclub o las series desde un deco.

No he encontrado la solución por más vueltas que le he dado, pero escribo este mensaje para ver si con mis avances alguien que realmente sepa de esto (y por aquí hay más de uno) me puede ayudar. Allá voy:

En la configuración antigua, nuestros decos tenían direcciones 10.x.y.z, que son direcciones de la propia red de Telefónica. No necesitábamos NAT porque cualquier respuesta de la red iba directamente al deco.

Ahora no es así. Los decos tienen direcciones privadas de nuestra subred y nos conectamos a la red IPTV utlizando NAT. Y al igual que en la WAN, el NAT funciona, para casi todo. Para entender por qué se queda en negro la pantalla con el unicast (series, videoclub, trailers) hice un tcpdump. Resulta que el unicast se hace negociando una sesión RTSP. El deco y la red se intercambian información y hasta aquí todo perfecto. Pero cuando empieza el vídeo ¡viene de una IP diferente! Diferente de la que se ha usado en la negociación. El cortafuegos acepta el video en la 10.x.y.z del router, por las reglas que tiene definidas, pero al ser una conexión nueva, no hay ninguna información en la tabla de NAT que permita dirigir el video al deco que lo pidió.

He probado todo (lo poco) que sé de iptables para encontrar una solución, pero sin éxito. He recompilado incluyendo los conntrack nat helpers (rtsp, RTP...) y tampoco. Quizá haya algún proxy RTSP (que tampoco he logrado encontrar) que resuelva el problema. También leí que hay una modalidad de NAT, llamada full cone NAT, que redirigiría correctamente una conexión entrante como ésta del unicast, pero no sé si se puede hacer con iptables.

En el camino he descubierto como configurar el DHCP para los decos, aunque con un deco no sé si vale la pena (hay que editar /etc/config/dhcp):

Código: [Seleccionar]
config vendorclass option vendorclass 'IAL' option networkid 'decoiptv' config dhcp 'lan' option interface 'lan' option networkid 'tag:!decoiptv' option start '40' option limit '59' option leasetime '24h' option dhcpv6 'hybrid' option ra 'hybrid' option ndp 'hybrid' list dhcp_option '252,\n' config dhcp 'decoiptv' option networkid 'tag:decoiptv' option interface 'lan' option start '200' option limit '10' option leasetime '24h' list dhcp_option '6,172.26.23.3,172.26.23.3' list dhcp_option '240,:::::239.0.2.10:22222:v6.0:239.0.2.30:22222'
No está completo, sólo he puesto la parte relevante.

Y hasta aquí he llegado. Espero haber ayudado y que me ayudéis. Gracias.

Muchas gracias por la configuración del DHCP, queda añadida la nueva versión r9.

Por otro lado, creo que resetear el router de Movistar al último firmware disponible ahora mismo activa de alguna forma un cambio en la configuración, de forma que aunque tengas la antigua, se cambia automáticamente a la nueva :/.

He estado haciendo pruebas en casa de mi hermana, que tiene la configuración nueva. El tema es que el VOD (Video On Demand) viene de 172.26.242.22 a la IP de la interfaz iptv (10.x.y.z) pero al haber NAT, no sabe a dónde debe redirigirla (en este caso, debería ser la IP de la LAN del deco 192.168.1.2xx).
Sospecho que esto no sucede en el firmware de Movistar dado que dispone de una NAT estilo "Full Cone NAT" (en español se conoce como NAT Independiente del Extremo), que es la menos restrictiva de todas las NAT.
Lo que hacemos en el script es establecer una norma que emula este tipo de NAT para una dirección IP concreta (el problema es que sólo se puede hacer para una dirección IP):

Código: [Seleccionar]

iptables -t nat -A PREROUTING -s 172.26.0.0/16 -p udp -d 10.x.y.z -j DNAT --to-destination 192.168.1.200
P.D: más o menos es lo que tú has dicho, pero aportando algún dato más.

Saludos.

psdos · « **Respuesta #374 en:** 19-05-2014, 00:55 (Lunes) »

Gracias Noltari por esta nueva revisión de tú script. La r8 la probé el otro día e iba genial. Si te pegas por aquí algun enlace de dropbox con alguna de tus compilaciones reciente con Barrier Braker 14.04 beta, hago de conejillo de indias para esta nueva versión de tú script.

Saludos.

deckar21 · « **Respuesta #375 en:** 19-05-2014, 11:18 (Lunes) »

Buenos dias,
Lo primero felicitar por este espectacular trabajo. Voy a comprarme el tplink 4300 para sustituir esa castaña que es el Contrend VG8050 (no he visto un router en el que el wifi funcione peor).
Tengo dos preguntas de principiante:
1. El flasheo a Openwrt la puedo hacer directamente desde el menu http del tplink? Hay que hacer algo en particular?
2. En el hilo se indica que al ejecutar el script hay que contestar en que boca esta conectada la ONT. El router tiene 4 puerto LAN y uno WAN. Sucede como con DD-WRT que se puede asignar el WAN a LAN y el WAN es considerando puerto 0?

Saludos y gracias

Noltari · « **Respuesta #376 en:** 20-05-2014, 19:43 (Martes) »

Cita de: deckar21 en 19-05-2014, 11:18 (Lunes)

Buenos dias,
Lo primero felicitar por este espectacular trabajo. Voy a comprarme el tplink 4300 para sustituir esa castaña que es el Contrend VG8050 (no he visto un router en el que el wifi funcione peor).
Tengo dos preguntas de principiante:
1. El flasheo a Openwrt la puedo hacer directamente desde el menu http del tplink? Hay que hacer algo en particular?
2. En el hilo se indica que al ejecutar el script hay que contestar en que boca esta conectada la ONT. El router tiene 4 puerto LAN y uno WAN. Sucede como con DD-WRT que se puede asignar el WAN a LAN y el WAN es considerando puerto 0?

Saludos y gracias

El flasheo de OpenWrt lo puedes hacer directamente desde el menú del TP-Link, siempre y cuando sea la imagen que contiene "factory" en el nombre.
Sólo tienes que usar la imagen factory la primera vez. El resto de actualizaciones siempre y cuando flashees desde OpenWrt debes usar la imagen "sysupgrade".
La boca del switch depende de cada router. En el caso del WDR4300 es la 1, o al menos lo es en el mío (podría cambiar según la revisión del hardware, pero no creo).

Cita de: psdos en 19-05-2014, 00:55 (Lunes)

Gracias Noltari por esta nueva revisión de tú script. La r8 la probé el otro día e iba genial. Si te pegas por aquí algun enlace de dropbox con alguna de tus compilaciones reciente con Barrier Braker 14.04 beta, hago de conejillo de indias para esta nueva versión de tú script.

Saludos.

Aquí la tienes.
Tiene algún que otro añadido, como un parche solucionar bugs en la configuración de las VLANs (untagged + tagged) del switch AR8327.
https://dl.dropboxusercontent.com/u/4708147/openwrt/ar71xx/WDR4300/openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-sysupgrade_r40624.bin

Saludos.

jfm · « **Respuesta #377 en:** 20-05-2014, 21:10 (Martes) »

Acabo de releer el inicio de hilo para ver los cambios en el script y quería comentar algo que me llama la atención:

Citar

•Simplificada la regla que habilita los menús de Imagenio en las configuraciones nuevas (ahora es un simple forward wan->iptv).

En mi humilde opinión esa regla es un agujero de seguridad y no debería utilizarse. Toda la red IPTV está soportada en direcciones privadas 172.26.x.y y para que nos funcione en casa (confiando en que Telefónica habrá securizado bien su red) no nos queda otra que dejar la puerta muy abierta entre la vlan 2 y nuestra lan. Si desde la wan se puede hacer forward de cualquier cosa hacia la vlan 2 y de ahí a la lan, nuestra red local queda totalmente expuesta ¿me equivoco?

Hipótesis: los menús se piden como páginas web, 1º al DNS (172.26.23.3) y así se obtiene la dirección de la página con los menús (otra 172.26.x.y). Esta nueva dirección no ha sido informada vía RIP/bird y por tanto ¿qué hace el router cuando el deco intenta descargarla? pues la pide por la wan y la red de Telefónica, que conoce estas direcciones aunque sean privadas, nos contesta por la misma vlan por la que hemos pedido la página, la 6, la de la wan.

La idea es que TODO el tráfico de iptv debería ir por la vlan 2. Lo que yo he puesto en /etc/config/network es una ruta estática:

Código: [Seleccionar]

config route 'lantoiptv'
	option interface 'lan'
	option target '172.26.0.0'
	option netmask '255.255.0.0'
	option gateway '10.128.0.1'
	option metric '3'

Esto combinado con la regla de DHCP que puse en mi anterior mensaje, que garantiza que los decos no usan otro DNS que no sea el 172.26.23.3, creo que permite funcionar sin ese forward (a mí me funciona sin él)

PD 1: recordatorio, tengo la configuración nueva de imagenio.

PD 2: tengo una idea para que funcione el unicast con varios decos, pero necesitaría la ayuda de alguien que programe en C (con sockets). Yo hace más de 25 años que no escribo una línea de código y no ando sobrado de tiempo. Se trataría de hacer un "hole puncher" (un perforador de agujeros en el firewall). ¿Algún voluntario?

Noltari · « **Respuesta #378 en:** 21-05-2014, 11:02 (Miércoles) »

Cita de: jfm en 20-05-2014, 21:10 (Martes)

Acabo de releer el inicio de hilo para ver los cambios en el script y quería comentar algo que me llama la atención:

Citar
•Simplificada la regla que habilita los menús de Imagenio en las configuraciones nuevas (ahora es un simple forward wan->iptv).

En mi humilde opinión esa regla es un agujero de seguridad y no debería utilizarse. Toda la red IPTV está soportada en direcciones privadas 172.26.x.y y para que nos funcione en casa (confiando en que Telefónica habrá securizado bien su red) no nos queda otra que dejar la puerta muy abierta entre la vlan 2 y nuestra lan. Si desde la wan se puede hacer forward de cualquier cosa hacia la vlan 2 y de ahí a la lan, nuestra red local queda totalmente expuesta ¿me equivoco?

Hipótesis: los menús se piden como páginas web, 1º al DNS (172.26.23.3) y así se obtiene la dirección de la página con los menús (otra 172.26.x.y). Esta nueva dirección no ha sido informada vía RIP/bird y por tanto ¿qué hace el router cuando el deco intenta descargarla? pues la pide por la wan y la red de Telefónica, que conoce estas direcciones aunque sean privadas, nos contesta por la misma vlan por la que hemos pedido la página, la 6, la de la wan.

La idea es que TODO el tráfico de iptv debería ir por la vlan 2. Lo que yo he puesto en /etc/config/network es una ruta estática:

Código: [Seleccionar]
config route 'lantoiptv' option interface 'lan' option target '172.26.0.0' option netmask '255.255.0.0' option gateway '10.128.0.1' option metric '3'
Esto combinado con la regla de DHCP que puse en mi anterior mensaje, que garantiza que los decos no usan otro DNS que no sea el 172.26.23.3, creo que permite funcionar sin ese forward (a mí me funciona sin él)

PD 1: recordatorio, tengo la configuración nueva de imagenio.

PD 2: tengo una idea para que funcione el unicast con varios decos, pero necesitaría la ayuda de alguien que programe en C (con sockets). Yo hace más de 25 años que no escribo una línea de código y no ando sobrado de tiempo. Se trataría de hacer un "hole puncher" (un perforador de agujeros en el firewall). ¿Algún voluntario?

La regla que había antes era:

Código: [Seleccionar]

uci add firewall rule &> /dev/null
uci set firewall.@rule[-1].target="ACCEPT" &> /dev/null
uci set firewall.@rule[-1].src="wan" &> /dev/null
uci set firewall.@rule[-1].dest="iptv" &> /dev/null
uci set firewall.@rule[-1].enabled="1" &> /dev/null
uci set firewall.@rule[-1].name="iptv_menu" &> /dev/null
uci set firewall.@rule[-1].proto="all" &> /dev/null

Que al final viene a ser interpretada como un forward por el firewall de OpenWrt, por lo que está igual que estaba, pero la definición es más simple.

Por otro lado, de acuerdo con lo que dices sobre la ruta estática, podría sustituir a bird4 por completo, ya que todas las rutas que importa bird por RIPv2 son subredes de 172.26.0.0/16. De todas formas, es un fallo que movistar no defina una ruta por RIPv2 para que las peticiones a su DNS vayan por la VLAN 2. Lo investigaré cuando tenga tiempo.

Por último, yo sé programar en C, pero no sé si llego a tanto para enterarme de cómo hacer lo que sugieres xD.

Saludos.

jfm · « **Respuesta #379 en:** 21-05-2014, 16:34 (Miércoles) »

Cita de: Noltari en 21-05-2014, 11:02 (Miércoles)

La regla que había antes era:
Código: [Seleccionar]
uci add firewall rule &> /dev/null uci set firewall.@rule[-1].target="ACCEPT" &> /dev/null uci set firewall.@rule[-1].src="wan" &> /dev/null uci set firewall.@rule[-1].dest="iptv" &> /dev/null uci set firewall.@rule[-1].enabled="1" &> /dev/null uci set firewall.@rule[-1].name="iptv_menu" &> /dev/null uci set firewall.@rule[-1].proto="all" &> /dev/null
Que al final viene a ser interpretada como un forward por el firewall de OpenWrt, por lo que está igual que estaba, pero la definición es más simple.

Noltari, tampoco tengo esa regla que había antes. Yo me leí tu script y fui configurando a mano sobre la marcha. Y me funciona.

Cita de: Noltari en 21-05-2014, 11:02 (Miércoles)

podría sustituir a bird4 por completo

Creo que bird te seguiría haciendo falta para la voz ip. No he probado a quitarlo de la iptv.

Cita de: Noltari en 21-05-2014, 11:02 (Miércoles)

Por último, yo sé programar en C, pero no sé si llego a tanto para enterarme de cómo hacer lo que sugieres xD.

Muchas gracias por el ofrecimiento. Yo lo cuento y si se puede perfecto. Si no, seguiré dándole vueltas a ver si hay alguna solución más sencilla.

La idea sería crear un socket que escuche las peticiones TCP de la lan a una dirección 172.26.x.y puerto 554 (RTSP). Cuando llega una de esas peticiones guardo la ip de origen y le aplico un temporizador (podría ser muy corto, 1 o 2 segundos). Si llega un mensaje con las mismas características de la misma ip, reseteo el temporizador (le alargo la vida). Si es de otra ip de la lan, creo un nuevo registro. Si vence el temporizador borro el registro. Son pocos datos porque no creo que haya mucha gente con más de 2 decos.

En un 2º socket escuchamos nuevas conexiones entrantes UDP con destino a nuestra ip de la vlan 2 (10.x.y.z), con origen en una 172.26.x.y con puerto alto (>1024). Al llegar una de éstas miramos la lista anterior (hacemos la hipótesis de que las respuestas llegan en el mismo orden en que salieron las peticiones) y generamos un ping con origen la ip de nuestra lan más antigua de la lista y destino la ip de origen del paquete UDP que acabamos de recibir. Borramos esa ip de origen de nuestra lista y ya está.

El ping que enviemos debería crear en la tabla nat la entrada necesaria para abrir el cortafuegos y aunque no haya respuesta al ping, el siguiente paquete UDP debiera entrar por el camino que acabamos de abrir y llegar al deco correcto.

Esa es la idea. Yo creo que funcionaría salvo casos extremos de solapes de peticiones unicast en varios decos a la vez.

Saludos.

Noticias:

Autor Tema: [Tutorial] Movistar FTTH con OpenWrt (VOIP e Imagenio) (Leído 877581 veces)

astrak

Morax

Noltari

Morax

arrobar

astrak

Noltari

arrobar

Morax

Pteridium

Morax

Colerax

Noltari

Noltari

psdos

deckar21

Noltari

jfm

Noltari

jfm