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

jordipalet · « **Respuesta #1240 en:** 08-02-2018, 12:16 (Jueves) »

Hola,

No se si es que este hilo ya no esta vivo, pero claro, cuando busco Imagenio ... aparecen mil ...

He probado con

Tengo todo configurado con LEDE y funcionando, pero dos dudas:
1) Es necesario ponerle al deco el DNS 172.26.23.3 ? He probado con ese DNS y con otros y no noto diferencia salvo que se me escape algo.
2) No me funcionan las opciones de grabación, VOD, ver programas desde el principio, tecla del mando menu, etc. (he probado con el DNS 172.26.23.3 y con otros). Alguna idea de cual puede ser el problema?

Notas:
- Las opciones DHCP 240 el deco las recibe bien (239.0.2.10:22222 y 239.0.2.30:22222)
- He probado con omcproxy, mcproxy o igmpproxy, y al final he dejado el que creo que es mas moderno (omcproxy)
- Con VLC y otras aplicaciones accedo sin problemas tanto desde la red cableada como WiFi a los canales por rtp/multicast, pero tampoco puedo ver los programas en otro momento, solo directo

Gracias!

jordipalet · « **Respuesta #1241 en:** 15-02-2018, 14:47 (Jueves) »

Ya lo tengo andando, pongo aquí los cambios que he hecho, por si a alguno le pasa.

Me he basado en el documento de Noltari v1.2 (creo que es la última). Solo he usado la parte de Imagenio, porque tengo una red bastante complicada y la parte de datos y de VoIP ya lo tenía funcionando perfectamente.

Según eso, bajo mi punto de vista, lo que me ha funcionado para poder acceder al VOD, menus, grabaciones, etc. es modificar esta zona del firewall:

config zone
option name 'iptv'
option input 'ACCEPT'
option output 'ACCEPT'
option network 'iptv'
option masq '1'
option forward 'REJECT'

(el cambio es option masq '1')

Para el Bird4, como uso algunas direcciones de la red 172 internamente, en /etc/bird4.conf he cambiado el /12 por un /16:

filter iptv_filter {
if net ~ 172.26.0.0/16 then accept;
else reject;
}

Y finalmente, si se quiere usar omcproxy, en /etc/config/omcproxy:

config proxy
   option scope global
   option uplink iptv
   list downlink lan

Foguet · « **Respuesta #1242 en:** 15-02-2018, 18:56 (Jueves) »

Cita de: jordipalet en 15-02-2018, 14:47 (Jueves)

Ya lo tengo andando, pongo aquí los cambios que he hecho, por si a alguno le pasa.

Me he basado en el documento de Noltari v1.2 (creo que es la última). Solo he usado la parte de Imagenio, porque tengo una red bastante complicada y la parte de datos y de VoIP ya lo tenía funcionando perfectamente.

Según eso, bajo mi punto de vista, lo que me ha funcionado para poder acceder al VOD, menus, grabaciones, etc. es modificar esta zona del firewall:

config zone
option name 'iptv'
option input 'ACCEPT'
option output 'ACCEPT'
option network 'iptv'
option masq '1'
option forward 'REJECT'

(el cambio es option masq '1')

Para el Bird4, como uso algunas direcciones de la red 172 internamente, en /etc/bird4.conf he cambiado el /12 por un /16:

filter iptv_filter {
if net ~ 172.26.0.0/16 then accept;
else reject;
}

Y finalmente, si se quiere usar omcproxy, en /etc/config/omcproxy:

config proxy
   option scope global
   option uplink iptv
   list downlink lan

Muchas gracias por la solución! A mi también me fallaba pero no he tenido tiempo de probarlo... Así que casi que usaba poco la tele

Lesgar · « **Respuesta #1243 en:** 18-05-2018, 00:00 (Viernes) »

El script funciona de maravilla, gracias por compartirlo.

Solo tengo una duda al usarlo en kernels >=4.7, ni la grabación, ni el VOD funciona y tengo instalado el paquete kmod-ipt-nathelper-rtsp.
Buscando por internet he encontrado que a partir de los kernels >=4.7 están desaprobando la asignación de puertos del módulo auxiliar automático a favor de reglas explícitas.

¿Como se pueden crear estas reglas?

De momento lo tengo solucionado rehabilitando el modulo auxiliar asi:
"echo net.netfilter.nf_conntrack_helper=1 > /etc/sysctl.d/local.conf"

hardwarer · « **Respuesta #1244 en:** 18-05-2018, 03:41 (Viernes) »

A ver si alguien me puede ayudar:

Tengo una ONT alcatel lucent G-010G-P, es de vodafone y le he cambiado el IDONT poniendo el de movistar. He quitado el router Mitrastar y he puesto un router TPlink C7 con Lede 17.01 conectado a la ONT lucent por el puerto WAN con sus vlans eth0.3 y eth0.6. Bueno todo funciona bien, se conecta a internet y tengo telefono fijo por VoIP(no tengo contratado TV). EL unico problema que veo es que si apago la ONT, al volver a encenderla no tengo internet, en el log del TpLink repite hasta el infinito "Timeout waiting for PADO packets"(lo he dejado varias horas). Esto pasa siempre que apago la ONT de alcatel y la vuelvo a encender, o también si quito el cable de fibra y lo vuelvo a poner. La unica solución, y esto es lo extraño, es conectar el Mitrastar de movistar, esperar a que se conecte a internet y luego quitarle el cable de fibra optica y ponerselo al Alcatel. Haciendo esto el Tplink ya levanta la session PPPoE sin problemas.
¿alguna idea de que puede estar pasando?

Tki2000 · « **Respuesta #1245 en:** 18-05-2018, 08:35 (Viernes) »

Cita de: hardwarer en 18-05-2018, 03:41 (Viernes)

A ver si alguien me puede ayudar:

Tengo una ONT alcatel lucent G-010G-P, es de vodafone y le he cambiado el IDONT poniendo el de movistar. He quitado el router Mitrastar y he puesto un router TPlink C7 con Lede 17.01 conectado a la ONT lucent por el puerto WAN con sus vlans eth0.3 y eth0.6. Bueno todo funciona bien, se conecta a internet y tengo telefono fijo por VoIP(no tengo contratado TV). EL unico problema que veo es que si apago la ONT, al volver a encenderla no tengo internet, en el log del TpLink repite hasta el infinito "Timeout waiting for PADO packets"(lo he dejado varias horas). Esto pasa siempre que apago la ONT de alcatel y la vuelvo a encender, o también si quito el cable de fibra y lo vuelvo a poner. La unica solución, y esto es lo extraño, es conectar el Mitrastar de movistar, esperar a que se conecte a internet y luego quitarle el cable de fibra optica y ponerselo al Alcatel. Haciendo esto el Tplink ya levanta la session PPPoE sin problemas.
¿alguna idea de que puede estar pasando?

No sé cómo lo hace Movistar, pero algunos ISP no autorizan la línea, hasta que la ONT les comunique la versión de firmware quie tienen instalada, o el fabricante, para asegurarse de que es compatible, aparte del IDONT y todo lo demás. Depende de los datos que se comprueben en el otro extremo, lo de cambiar sólo la IDONT funcionará o no.
Alguien con más datos concretos, a lo mejor te puede decir algo más.

hardwarer · « **Respuesta #1246 en:** 19-05-2018, 00:09 (Sábado) »

Cita de: Tki2000 en 18-05-2018, 08:35 (Viernes)

Cita de: hardwarer en 18-05-2018, 03:41 (Viernes)
A ver si alguien me puede ayudar:

Tengo una ONT alcatel lucent G-010G-P, es de vodafone y le he cambiado el IDONT poniendo el de movistar. He quitado el router Mitrastar y he puesto un router TPlink C7 con Lede 17.01 conectado a la ONT lucent por el puerto WAN con sus vlans eth0.3 y eth0.6. Bueno todo funciona bien, se conecta a internet y tengo telefono fijo por VoIP(no tengo contratado TV). EL unico problema que veo es que si apago la ONT, al volver a encenderla no tengo internet, en el log del TpLink repite hasta el infinito "Timeout waiting for PADO packets"(lo he dejado varias horas). Esto pasa siempre que apago la ONT de alcatel y la vuelvo a encender, o también si quito el cable de fibra y lo vuelvo a poner. La unica solución, y esto es lo extraño, es conectar el Mitrastar de movistar, esperar a que se conecte a internet y luego quitarle el cable de fibra optica y ponerselo al Alcatel. Haciendo esto el Tplink ya levanta la session PPPoE sin problemas.
¿alguna idea de que puede estar pasando?

No sé cómo lo hace Movistar, pero algunos ISP no autorizan la línea, hasta que la ONT les comunique la versión de firmware quie tienen instalada, o el fabricante, para asegurarse de que es compatible, aparte del IDONT y todo lo demás. Depende de los datos que se comprueben en el otro extremo, lo de cambiar sólo la IDONT funcionará o no.
Alguien con más datos concretos, a lo mejor te puede decir algo más.

He buscado algo mas de información y como tu dices con Movistar el ONT se conecta a la central pero hace mas comprobaciones que la passwd, son 4 pasos y la password es el ultimo. Entiendo que al conectar el Mitrastar, se "abre la primera puerta" y queda abierta para conectar el ONT de alcatel.

yonoesio · « **Respuesta #1247 en:** 23-05-2018, 10:28 (Miércoles) »

Buenos días,

Tengo un WRT 1900AC V1 con Lede de Davidc502. Al duplicar la velocidad a 600 mbs no los alcanzo y me quedo en unos 500.
He probado con el router de movistar y alcanza los 600 sin problemas. No se si es por alguna configuración o es cosa de LEDE.

Teneis alguna idea?

Gracias

jlazkano · « **Respuesta #1248 en:** 23-05-2018, 10:32 (Miércoles) »

Cita de: yonoesio en 23-05-2018, 10:28 (Miércoles)

Buenos días,

Tengo un WRT 1900AC V1 con Lede de Davidc502. Al duplicar la velocidad a 600 mbs no los alcanzo y me quedo en unos 500.
He probado con el router de movistar y alcanza los 600 sin problemas. No se si es por alguna configuración o es cosa de LEDE.

Teneis alguna idea?

Gracias

Buenas,

Prueba a instalar htop y mira como va la CPU cuando haces la prueba:

opkg update
opkg install htop

Saludos.

yonoesio · « **Respuesta #1249 en:** 23-05-2018, 11:03 (Miércoles) »

Si no me equivoco... un nucleo al 100% y el otro al 50% mas o menos

eduperez · « **Respuesta #1250 en:** 24-05-2018, 07:51 (Jueves) »

Cita de: yonoesio en 23-05-2018, 10:28 (Miércoles)

Buenos días,

Tengo un WRT 1900AC V1 con Lede de Davidc502. Al duplicar la velocidad a 600 mbs no los alcanzo y me quedo en unos 500.
He probado con el router de movistar y alcanza los 600 sin problemas. No se si es por alguna configuración o es cosa de LEDE.

Teneis alguna idea?

Gracias

El router de Movistar hace el NAT por hardware en el propio switch interno, y es muy rápido; en cambio, LEDE / OpenWrt hace el NAT por software en la CPU principal, y es más lento.

Leí que para la próxima versión se estaba trabajando en implementar NAT por hardware, o una alternativa llamada fast-path, pero no te sabría decir en qué situación se encuentra ese trabajo. En los foros de LEDE hay algunos hilos sobre el tema, por si quieres probar con alguno de los parches que circulan.

jlazkano · « **Respuesta #1251 en:** 24-05-2018, 08:00 (Jueves) »

Parece que ahi esta el problema, LEDE hace NAT y swich mediante software.

Yo hace tiempo que no utilizo LEDE para router, solo para AP. Con las velocidades actuales que no tenga implementado el NAT/switch por hardware es un problema.

Un saludo.

Cita de: yonoesio en 23-05-2018, 11:03 (Miércoles)

Si no me equivoco... un nucleo al 100% y el otro al 50% mas o menos

Tki2000 · « **Respuesta #1252 en:** 25-05-2018, 08:15 (Viernes) »

Cita de: jlazkano en 24-05-2018, 08:00 (Jueves)

Parece que ahi esta el problema, LEDE hace NAT y swich mediante software.

Yo hace tiempo que no utilizo LEDE para router, solo para AP. Con las velocidades actuales que no tenga implementado el NAT/switch por hardware es un problema.

Un saludo.
Cita de: yonoesio en 23-05-2018, 11:03 (Miércoles)
Si no me equivoco... un nucleo al 100% y el otro al 50% mas o menos

Me llama mucho la atención, la mentalidad de los usuarios, que piensan que tener algo funcionando, y que no sea a "tope" de sus posibilidades, no sirve para nada. Prefieren velocidad, aunque sea saltándose seguridad, que es lo que hacen los firmwares oficiales para conseguir ciertas velocidades, que seguridad a la hora de manejar datos, que es lo que hace openwrt.
Si la única utilidad que se le va a dar al router es correr, ¿para qué se molestan en cambiar el firmware si con el original ya corre?

Es como coger un coche que corre a 200, pero que es superligero y cualquier cosa nos puede agujerear el chasis, y cambiarle la carrocería, para blindarla y tener seguridad. El coche pesa más, y no podrá alcanzar la máxima velocidad, pero nadie con un coche blindado se queja de no poder ir a la máxima velocidad...

Sin (más) comentarios...

jlazkano · « **Respuesta #1253 en:** 25-05-2018, 08:33 (Viernes) »

Estoy completamente de acuerdo contigo, pero no me vas a negar que con 300 o 600 mbps de acceso WAN, LEDE va justito enrutando.

Puede que sea cuestion de buscar un hardware mejor, pero yo no lo he encontrado a un precio razonable.

Para conexiones de menos de 100mbps no tengo duda que LEDE es la mejor opcion, sobre todo la flexibilidad que te da para hacer lo que quieras.

Un saludo.

Cita de: Tki2000 en 25-05-2018, 08:15 (Viernes)

Cita de: jlazkano en 24-05-2018, 08:00 (Jueves)
Parece que ahi esta el problema, LEDE hace NAT y swich mediante software.

Yo hace tiempo que no utilizo LEDE para router, solo para AP. Con las velocidades actuales que no tenga implementado el NAT/switch por hardware es un problema.

Un saludo.
Cita de: yonoesio en 23-05-2018, 11:03 (Miércoles)
Si no me equivoco... un nucleo al 100% y el otro al 50% mas o menos

Me llama mucho la atención, la mentalidad de los usuarios, que piensan que tener algo funcionando, y que no sea a "tope" de sus posibilidades, no sirve para nada. Prefieren velocidad, aunque sea saltándose seguridad, que es lo que hacen los firmwares oficiales, para conseguir ciertas velocidades, que seguridad a la hora de manejar datos, que es lo que hace openwrt.
Si la única utilidad que se le va a dar al router es correr, ¿para qué se molestan en cambiar el firmware si con el original ya corre?

Es como coger un coche que corre a 200, pero que es superligero y cualquier cosa nos puede agujerear el chasis, y cambiarle la carrocería, para blindarla y tener seguridad. El coche pesa más, y no podrá alcanzar la máxima velocidad, pero nadie con un coche blindado se queja de no poder ir a la máxima velocidad...

Sin (más) comentarios...

Tki2000 · « **Respuesta #1254 en:** 25-05-2018, 09:40 (Viernes) »

Cita de: jlazkano en 25-05-2018, 08:33 (Viernes)

Estoy completamente de acuerdo contigo, pero no me vas a negar que con 300 o 600 mbps de acceso WAN, LEDE va justito enrutando.

Puede que sea cuestion de buscar un hardware mejor, pero yo no lo he encontrado a un precio razonable.

Para conexiones de menos de 100mbps no tengo duda que LEDE es la mejor opcion, sobre todo la flexibilidad que te da para hacer lo que quieras.

Un saludo.
Cita de: Tki2000 en 25-05-2018, 08:15 (Viernes)
Cita de: jlazkano en 24-05-2018, 08:00 (Jueves)
Parece que ahi esta el problema, LEDE hace NAT y swich mediante software.

Yo hace tiempo que no utilizo LEDE para router, solo para AP. Con las velocidades actuales que no tenga implementado el NAT/switch por hardware es un problema.

Un saludo.
Cita de: yonoesio en 23-05-2018, 11:03 (Miércoles)
Si no me equivoco... un nucleo al 100% y el otro al 50% mas o menos

Me llama mucho la atención, la mentalidad de los usuarios, que piensan que tener algo funcionando, y que no sea a "tope" de sus posibilidades, no sirve para nada. Prefieren velocidad, aunque sea saltándose seguridad, que es lo que hacen los firmwares oficiales, para conseguir ciertas velocidades, que seguridad a la hora de manejar datos, que es lo que hace openwrt.
Si la única utilidad que se le va a dar al router es correr, ¿para qué se molestan en cambiar el firmware si con el original ya corre?

Es como coger un coche que corre a 200, pero que es superligero y cualquier cosa nos puede agujerear el chasis, y cambiarle la carrocería, para blindarla y tener seguridad. El coche pesa más, y no podrá alcanzar la máxima velocidad, pero nadie con un coche blindado se queja de no poder ir a la máxima velocidad...

Sin (más) comentarios...

Offtopic:

Todo se resuelve a lo mismo. ¿Para qué esperar 1:30 minutos a descargarse algo cuando podría hacerlo en 1:05? La paciencia escasea.
Si las 24h del día necesitas esa velocidad de acceso, algo hay que replantearse.
Si sólo la necesitas durante unos minutos al día, entonces estás desperdiciándola.
Un blu ray en streaming, sólo necesita 40Mbps.
Descargarse pelis sin poseerlas no es legal. ¿Para qué se necesita esa velocidad pues?

Warman · « **Respuesta #1255 en:** 21-07-2018, 09:52 (Sábado) »

Cita de: deskect en 09-07-2017, 19:57 (Domingo)

Cita de: jrierab en 07-07-2017, 21:18 (Viernes)
Funcionando con la última de LEDE y Fast Path activado !!!

Al final, todo era un tontería. Se ve que en algún momento se cambió la opción por defecto del mtu_fix en la WAN y se puso a cero, por lo que no negociaba correctamente el MTU.

Total, que lo único que hay que hacer es editar /etc/config/firewall y ponerlo en la zona wan:

Código: [Seleccionar]
... config zone option name wan list network 'wan' list network 'wan6' option input REJECT option output ACCEPT option forward REJECT option masq 1 option mtu_fix 1 ...

Le he puesto la versión experimental de LEDE con Fast Path activado. Más info en https://forum.lede-project.org/t/qualcomm-fast-path-for-lede/4582 y los FW más recientes (para algunos routers) están en https://github.com/gwlim/Fast-Path-LEDE-OpenWRT/tree/master/Fast-Path/July-2017.

Con esto he pasado de 70MB / 10MB en test de velocidad a 300MB / 250 MB, !!! Con el antiguo 1043NDv1. No está nada mal

He estado leyendo el hilo del fastpath y parece muy interesante, aunque para los que tenemos tele habria que compilar lede con dichos parches + los paquetes de kmod-bridge y kmod-ipt-nathelper-rtsp, ya incluidos directamente en la build, puesto que debido a las modificaciones de dichos parches para fastpath despues no es posible instalar ningun kmod desde opkg, por lo que no funcionaria la television.

Efectivamente actualice de la version 17.01.5 a la 18.06.0-rc2 y los paquetes kmod-bridge y kmod-ipt-nathelper-rtsp no están, ergo el VOD no funciona. Al final he vuelto a la versión antigua.

Por favor si tenéis alguna solución o paquetes alternativos os lo agradecería.

Tki2000 · « **Respuesta #1256 en:** 21-07-2018, 11:07 (Sábado) »

Cita de: Warman en 21-07-2018, 09:52 (Sábado)

Cita de: deskect en 09-07-2017, 19:57 (Domingo)
Cita de: jrierab en 07-07-2017, 21:18 (Viernes)
Funcionando con la última de LEDE y Fast Path activado !!!

Al final, todo era un tontería. Se ve que en algún momento se cambió la opción por defecto del mtu_fix en la WAN y se puso a cero, por lo que no negociaba correctamente el MTU.

Total, que lo único que hay que hacer es editar /etc/config/firewall y ponerlo en la zona wan:

Código: [Seleccionar]
... config zone option name wan list network 'wan' list network 'wan6' option input REJECT option output ACCEPT option forward REJECT option masq 1 option mtu_fix 1 ...

Le he puesto la versión experimental de LEDE con Fast Path activado. Más info en https://forum.lede-project.org/t/qualcomm-fast-path-for-lede/4582 y los FW más recientes (para algunos routers) están en https://github.com/gwlim/Fast-Path-LEDE-OpenWRT/tree/master/Fast-Path/July-2017.

Con esto he pasado de 70MB / 10MB en test de velocidad a 300MB / 250 MB, !!! Con el antiguo 1043NDv1. No está nada mal

He estado leyendo el hilo del fastpath y parece muy interesante, aunque para los que tenemos tele habria que compilar lede con dichos parches + los paquetes de kmod-bridge y kmod-ipt-nathelper-rtsp, ya incluidos directamente en la build, puesto que debido a las modificaciones de dichos parches para fastpath despues no es posible instalar ningun kmod desde opkg, por lo que no funcionaria la television.

Efectivamente actualice de la version 17.01.5 a la 18.06.0-rc2 y los paquetes kmod-bridge y kmod-ipt-nathelper-rtsp no están, ergo el VOD no funciona. Al final he vuelto a la versión antigua.

Por favor si tenéis alguna solución o paquetes alternativos os lo agradecería.

No sé si exactamente es lo que necesitas, pero en el repositorio veo los paquetes kmod-nft-bridge y kmod-ipt-nathelper-rtsp. ¿Son esos los que dices que faltan? ¿Qué arquitectura usas? En la ar71xx sí están esos paquetes.

Warman · « **Respuesta #1257 en:** 22-07-2018, 18:20 (Domingo) »

Cita de: Tki2000 en 21-07-2018, 11:07 (Sábado)

Cita de: Warman en 21-07-2018, 09:52 (Sábado)
Cita de: deskect en 09-07-2017, 19:57 (Domingo)
Cita de: jrierab en 07-07-2017, 21:18 (Viernes)
Funcionando con la última de LEDE y Fast Path activado !!!

Al final, todo era un tontería. Se ve que en algún momento se cambió la opción por defecto del mtu_fix en la WAN y se puso a cero, por lo que no negociaba correctamente el MTU.

Total, que lo único que hay que hacer es editar /etc/config/firewall y ponerlo en la zona wan:

Código: [Seleccionar]
... config zone option name wan list network 'wan' list network 'wan6' option input REJECT option output ACCEPT option forward REJECT option masq 1 option mtu_fix 1 ...

Le he puesto la versión experimental de LEDE con Fast Path activado. Más info en https://forum.lede-project.org/t/qualcomm-fast-path-for-lede/4582 y los FW más recientes (para algunos routers) están en https://github.com/gwlim/Fast-Path-LEDE-OpenWRT/tree/master/Fast-Path/July-2017.

Con esto he pasado de 70MB / 10MB en test de velocidad a 300MB / 250 MB, !!! Con el antiguo 1043NDv1. No está nada mal

He estado leyendo el hilo del fastpath y parece muy interesante, aunque para los que tenemos tele habria que compilar lede con dichos parches + los paquetes de kmod-bridge y kmod-ipt-nathelper-rtsp, ya incluidos directamente en la build, puesto que debido a las modificaciones de dichos parches para fastpath despues no es posible instalar ningun kmod desde opkg, por lo que no funcionaria la television.

Efectivamente actualice de la version 17.01.5 a la 18.06.0-rc2 y los paquetes kmod-bridge y kmod-ipt-nathelper-rtsp no están, ergo el VOD no funciona. Al final he vuelto a la versión antigua.

Por favor si tenéis alguna solución o paquetes alternativos os lo agradecería.

No sé si exactamente es lo que necesitas, pero en el repositorio veo los paquetes kmod-nft-bridge y kmod-ipt-nathelper-rtsp. ¿Son esos los que dices que faltan? ¿Qué arquitectura usas? En la ar71xx sí están esos paquetes.

Efectivamente están los paquetes que comentas pero el necesario para hacer funcionar las grabaciones y los U7 es el paquete kmod-bridge (que no esta disponible), acabo de probar con el que comentas kmod-nft-bridge y no funciona... Uso arquitectura ar71xx

Tki2000 · « **Respuesta #1258 en:** 23-07-2018, 11:02 (Lunes) »

Cita de: Warman en 22-07-2018, 18:20 (Domingo)

Cita de: Tki2000 en 21-07-2018, 11:07 (Sábado)
Cita de: Warman en 21-07-2018, 09:52 (Sábado)
Cita de: deskect en 09-07-2017, 19:57 (Domingo)
Cita de: jrierab en 07-07-2017, 21:18 (Viernes)
Funcionando con la última de LEDE y Fast Path activado !!!

Al final, todo era un tontería. Se ve que en algún momento se cambió la opción por defecto del mtu_fix en la WAN y se puso a cero, por lo que no negociaba correctamente el MTU.

Total, que lo único que hay que hacer es editar /etc/config/firewall y ponerlo en la zona wan:

Código: [Seleccionar]
... config zone option name wan list network 'wan' list network 'wan6' option input REJECT option output ACCEPT option forward REJECT option masq 1 option mtu_fix 1 ...

Le he puesto la versión experimental de LEDE con Fast Path activado. Más info en https://forum.lede-project.org/t/qualcomm-fast-path-for-lede/4582 y los FW más recientes (para algunos routers) están en https://github.com/gwlim/Fast-Path-LEDE-OpenWRT/tree/master/Fast-Path/July-2017.

Con esto he pasado de 70MB / 10MB en test de velocidad a 300MB / 250 MB, !!! Con el antiguo 1043NDv1. No está nada mal

He estado leyendo el hilo del fastpath y parece muy interesante, aunque para los que tenemos tele habria que compilar lede con dichos parches + los paquetes de kmod-bridge y kmod-ipt-nathelper-rtsp, ya incluidos directamente en la build, puesto que debido a las modificaciones de dichos parches para fastpath despues no es posible instalar ningun kmod desde opkg, por lo que no funcionaria la television.

Efectivamente actualice de la version 17.01.5 a la 18.06.0-rc2 y los paquetes kmod-bridge y kmod-ipt-nathelper-rtsp no están, ergo el VOD no funciona. Al final he vuelto a la versión antigua.

Por favor si tenéis alguna solución o paquetes alternativos os lo agradecería.

No sé si exactamente es lo que necesitas, pero en el repositorio veo los paquetes kmod-nft-bridge y kmod-ipt-nathelper-rtsp. ¿Son esos los que dices que faltan? ¿Qué arquitectura usas? En la ar71xx sí están esos paquetes.

Efectivamente están los paquetes que comentas pero el necesario para hacer funcionar las grabaciones y los U7 es el paquete kmod-bridge (que no esta disponible), acabo de probar con el que comentas kmod-nft-bridge y no funciona... Uso arquitectura ar71xx

Los módulos que veo que tienen que ver con ethernet bridging son:
kmod-br-netfilter
kmod-ipt-physdev
que dependen de kmod-ipt-core
No sé si serán los necesarios. No tengo movistar, así que no utilizo todo esto.
Si no es lo adecuado, esperemos que alguien con más idea se pase por aquí y aporte algo de luz sobre esto.

parpit · « **Respuesta #1259 en:** 31-08-2018, 10:55 (Viernes) »

Hola,
Tengo instalado todo esto (gracias Noltari), con la versión que aparece en el hilo y me preguntaba si se puede actualizar a la última versión de OpenWRT (OpenWrt 18.06.1) y si hay alguna mejora y merece la pena actualizar.

Como único problema que tengo es que a veces la wifi deja de funcionar, creo que es por que el chromecast me satura la wifi y tengo que reiniciarla.
La verdad es que tengo un nivel bajo de redes por lo que no se si habría que hacer muchos cambio para actualizar de versión.

Muchas gracias.

Noticias:

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

jordipalet

jordipalet

Foguet

Lesgar

hardwarer

hardwarer

yonoesio

jlazkano

yonoesio

eduperez

jlazkano

jlazkano

Warman

Warman

parpit