[TUTO] Ver Movistar+ en una segunda vivienda
22-feb-2026 10:28
#391
|
Edito: He seguido el tutorial completo con dos Cudy TR3000 pero en cliente no inicia el Deco. Se queda en la típica pantalla de que no hay conexión. No avanza. ¿Algún alma caritativa que pueda decirme que puede estar ocurriendo? ChatGPT me indica que el problema puede que tap0 NO está añadido al bridge LAN del servidor (me indica que es problema del server no del cliente), pero me extrañaría que haya algún fallo de config en el servidor pues he incluido el script tal cual y no ha dado fallo alguno. Este es el log que me arroja el router cliente desde Luci: Edito de nuevo. Creo que el server pudo quedar mal configurado porque por error le pasé al router server el script otherclient de cliente y después me di cuenta del error y sin “resetear” el router le pasé el script correcto de server, que creo que no sobre-escribe alguna de las reglas que fijó el script del cliente. Probaré a un reset del servidor con instalación de 0 correcta del script correcto y os digo. ¿Creéis que puede ser esto? Gracias de nuevo! |
Editado: 28-feb-2026 01:58 -
23-feb-2026 18:16
#392
|
Imagina hacer debug de algo que no sabes ni cómo está montado. Tcpdump muestra a tu deco pidiendo Ip por DHCP pero no es capaz de hablar con el HGU y se queda sin IP. Yo empezaria de cero, no pongas los scripts del firewall que puse hasta que no tengas el deco funcionando. Cambia el direcionamiento de una de las casas para no solaparlos. Si no sabes dónde está tu tap0 usa el comando brctl show. Edito:
He seguido el tutorial completo con dos Cudy TR3000 pero en cliente no inicia el Deco. Se queda en la típica pantalla de que no hay conexión. No avanza. ¿Algún alma caritativa que pueda decirme que puede estar ocurriendo? ChatGPT me indica que el problema puede que tap0 NO está añadido al bridge LAN del servidor (me indica que es problema del server no del cliente), pero me extrañaría que haya algún fallo de config en el servidor pues he incluido el script tal cual y no ha dado fallo alguno. Este es el log que me arroja el router cliente desde Luci: Código:
Sun Feb 22 19:12:30 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: [server] Inactivity timeout (--ping-restart), restarting Sun Feb 22 19:12:30 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: /usr/libexec/openvpn-hotplug route-pre-down VPN_Tap_Client tap0 1500 0 init Sun Feb 22 19:12:30 2026 https://daemon.notice netifd: Network device 'tap0' link is down Sun Feb 22 19:12:30 2026 https://kern.info kernel: [ 27.692053] br-vpn: port 2(tap0) entered disabled state Sun Feb 22 19:12:30 2026 https://kern.info kernel: [ 27.698037] tap0 (unregistering): left allmulticast mode Sun Feb 22 19:12:30 2026 https://kern.info kernel: [ 27.703371] tap0 (unregistering): left promiscuous mode Sun Feb 22 19:12:30 2026 https://kern.info kernel: [ 27.708627] br-vpn: port 2(tap0) entered disabled state Sun Feb 22 19:12:31 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: /usr/libexec/openvpn-hotplug down VPN_Tap_Client tap0 1500 0 init Sun Feb 22 19:12:31 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: SIGUSR1[soft,ping-restart] received, process restarting Sun Feb 22 19:12:31 2026 https://daemon.notice netifd: bridge 'br-vpn' link is down Sun Feb 22 19:12:31 2026 https://daemon.notice netifd: Interface 'vpn' has link connectivity loss Sun Feb 22 19:12:31 2026 https://daemon.notice netifd: Interface 'vpn' is now down Sun Feb 22 19:12:32 2026 https://daemon.warn openvpn(VPN_Tap_Client)[2364]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Feb 22 19:12:32 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: TCP/UDP: Preserving recently used remote address: [AF_INET]IP EDITADA:1194 Sun Feb 22 19:12:32 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: UDPv4 link local: (not bound) Sun Feb 22 19:12:32 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: UDPv4 link remote: [AF_INET]IP EDITADA:1194 Sun Feb 22 19:12:32 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: [server] Peer Connection Initiated with [AF_INET]IP EDITADA7:1194 Sun Feb 22 19:12:32 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: TUN/TAP device tap0 opened Sun Feb 22 19:12:32 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: /usr/libexec/openvpn-hotplug up VPN_Tap_Client tap0 1500 0 init Sun Feb 22 19:12:32 2026 https://kern.info kernel: [ 28.939518] br-vpn: port 2(tap0) entered blocking state Sun Feb 22 19:12:32 2026 https://kern.info kernel: [ 28.944754] br-vpn: port 2(tap0) entered disabled state Sun Feb 22 19:12:32 2026 https://kern.info kernel: [ 28.950040] tap0: entered allmulticast mode Sun Feb 22 19:12:32 2026 https://kern.info kernel: [ 28.954385] tap0: entered promiscuous mode Sun Feb 22 19:12:32 2026 https://kern.info kernel: [ 28.958744] br-vpn: port 2(tap0) entered blocking state Sun Feb 22 19:12:32 2026 https://kern.info kernel: [ 28.963976] br-vpn: port 2(tap0) entered forwarding state Sun Feb 22 19:12:32 2026 https://daemon.notice netifd: Network device 'tap0' link is up Sun Feb 22 19:12:32 2026 https://daemon.notice netifd: bridge 'br-vpn' link is up Sun Feb 22 19:12:32 2026 https://daemon.notice netifd: Interface 'vpn' has link connectivity Sun Feb 22 19:12:32 2026 https://daemon.notice netifd: Interface 'vpn' is setting up now Sun Feb 22 19:12:32 2026 https://daemon.notice netifd: Interface 'vpn' is now up Sun Feb 22 19:12:32 2026 https://daemon.notice openvpn(VPN_Tap_Client)[2364]: Initialization Sequence Completed Sun Feb 22 19:12:40 2026 https://daemon.err uhttpd[1977]: [info] luci: accepted login on / for root from 192.168.1.206 Sun Feb 22 19:13:44 2026 https://kern.info kernel: [ 101.236809] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off Sun Feb 22 19:13:44 2026 https://kern.info kernel: [ 101.236839] br-vpn: port 1(eth0) entered blocking state Sun Feb 22 19:13:44 2026 https://daemon.notice netifd: Network device 'eth0' link is up Sun Feb 22 19:13:44 2026 https://kern.info kernel: [ 101.250476] br-vpn: port 1(eth0) entered forwarding state Sun Feb 22 19:14:05 2026 https://daemon.notice netifd: Network device 'eth0' link is down Sun Feb 22 19:14:05 2026 https://kern.info kernel: [ 122.573776] mtk_soc_eth 15100000.ethernet eth0: Link is Down Sun Feb 22 19:14:05 2026 https://kern.info kernel: [ 122.580191] br-vpn: port 1(eth0) entered disabled state Sun Feb 22 19:14:08 2026 https://kern.info kernel: [ 125.569030] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off Sun Feb 22 19:14:08 2026 https://kern.info kernel: [ 125.569062] br-vpn: port 1(eth0) entered blocking state Sun Feb 22 19:14:08 2026 https://kern.info kernel: [ 125.582693] br-vpn: port 1(eth0) entered forwarding state Sun Feb 22 19:14:08 2026 https://daemon.notice netifd: Network device 'eth0' link is up Edito para añadir la info que me arroja SSH con tcpdump: Código:
root@OpenWrt:~# tcpdump -ni tap0 -e -vv
tcpdump: listening on tap0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:57:17.176804 MAC MODIFICADA > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
0.0.0.0 > 224.0.0.1: igmp query v2
18:57:37.321636 MAC MODIFICADA > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
0.0.0.0 > 224.0.0.1: igmp query v2
18:57:40.321825 MAC MODIFICADA > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
0.0.0.0 > 224.0.0.1: igmp query v2
18:57:40.940047 MAC MODIFICADA > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from MAC MODIFICADA, length 548, xid 0xfc0ec764, Flags [none] (0x0000)
Client-Ethernet-Address MAC MODIFICADA
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Client-ID (61), length 26: hardware-type 65, 52:52:49:53:5f:56:49:50:35:32:34:32:5f:46:43:41:45:33:34:34:30:36:35:46:45
Unknown (125), length 36: 3561,520160816,808464953,1107430470,1128351027,875835446,893797635,123095376,892482610
Hostname (12), length 26: "ARRIS_VIP5242_MACOCULTADA"
Vendor-Class (60), length 5: "[IAL]"
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), Unknown (125), Unknown (170)
Unknown (240), Unknown (241), Unknown (242), Unknown (243)
18:57:43.020229 MAC MODIFICADA > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from MAC MODIFICADA, length 548, xid 0xfc0ec764, Flags [none] (0x0000)
Client-Ethernet-Address MAC MODIFICADA
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Client-ID (61), length 26: hardware-type 65, 52:52:49:53:5f:56:49:50:35:32:34:32:5f:46:43:41:45:33:34:34:30:36:35:46:45
Unknown (125), length 36: 3561,520160816,808464953,1107430470,1128351027,875835446,893797635,123095376,892482610
Hostname (12), length 26: "ARRIS_VIP5242_MACOCULTADA"
Vendor-Class (60), length 5: "[IAL]"
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), Unknown (125), Unknown (170)
Unknown (240), Unknown (241), Unknown (242), Unknown (243)
18:57:45.110137 MAC MODIFICADA > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from MAC MODIFICADA, length 548, xid 0xfc0ec764, Flags [none] (0x0000)
Gracias de nuevo! |
23-feb-2026 20:17
#393
|
Buenas tardes creo que ya sé cual es el problema. Lo de los 10 minutos al conectar el cliente. Si yo enciendo la regleta funciona perfectamente al momento del deco cliente. Si sigo haciendo pruebas de apagar o encender regleta, tarda 10 minutos en conectar. Pero si dejo pasar 24 horas, y lo pruebo al dia siguiente y enciendo la regleta funciona al momento, la primera vez funciona al momento. Si sigo haciendo pruebas, las siguientes veces tarda minimo 10 minutos al conectar. Hoy he llegado y lo he puesto, y al momento funcionando la primera vez, las siguientes veces siguiendo pruebas, nada tarda 10 minutos. Puede que sea algo del keepalive 300 10 o algo de eso de la configuración del certificado openvpn?? gracias de antebrazo!! |
23-feb-2026 20:45
#394
|
A los 5/10 min se limpia la caché de los routers, por lo que cuentas tienes que tener un envenenamiento de la caché arp en algún router. Pero todo esto es elucubrar y hablar por hablar, lo único que te va a decir qué pasa es poner a trabajar tcpdump. Pregunta a la IA como capturar con tcpdump para ver qué pasa realmente. El deco recibe IP cuando no conecta???? Buenas tardes creo que ya sé cual es el problema. Lo de los 10 minutos al conectar el cliente.
Si yo enciendo la regleta funciona perfectamente al momento del deco cliente. Si sigo haciendo pruebas de apagar o encender regleta, tarda 10 minutos en conectar. Pero si dejo pasar 24 horas, y lo pruebo al dia siguiente y enciendo la regleta funciona al momento, la primera vez funciona al momento. Si sigo haciendo pruebas, las siguientes veces tarda minimo 10 minutos al conectar. Hoy he llegado y lo he puesto, y al momento funcionando la primera vez, las siguientes veces siguiendo pruebas, nada tarda 10 minutos. Puede que sea algo del keepalive 300 10 o algo de eso de la configuración del certificado openvpn?? gracias de antebrazo!! |
23-feb-2026 23:06
#395
|
Imagina hacer debug de algo que no sabes ni cómo está montado.
Tcpdump muestra a tu deco pidiendo Ip por DHCP pero no es capaz de hablar con el HGU y se queda sin IP. Yo empezaria de cero, no pongas los scripts del firewall que puse hasta que no tengas el deco funcionando. Cambia el direcionamiento de una de las casas para no solaparlos. Si no sabes dónde está tu tap0 usa el comando brctl show. ¿Creéis que ese error de cargarle el script del router cliente al router servidor y luego sobreescribirlo con el script correcto del router servidor es lo que me puede estar generando que mi deco cliente no obtenga IP? El fallo creo que está en origen, en el router servidor que es el que configure mal, y no en el cliente. En todo caso, resetearé ambos routers a “fábrica” y comenzaré de 0. Cuando logre la conexión con el tutorial del OP ya me pondré con tus firewall. Muchas gracias. |
24-feb-2026 10:26
#397
| Pilladas un par de NanoPi r2s para hacer servidor y cliente más un deco por Wallapop. A ver que podemos hacer. |
24-feb-2026 20:26
#398
|
Gracias! No, todavía no pase tus comandos del firewall. Me refiero a que de momento solo he seguido el tuto original del OP, y con las prisas, metí en el router servidor el script del openvpn del router cliente. Cuando me di cuenta que me había equivocado (porque el archivo de config me arrojaba el resultado del archivo de config del router cliente) metí a capón el script del router servidor, y creo que ese error inicial dejó alguna configuración errónea que me impide la conexión.
¿Creéis que ese error de cargarle el script del router cliente al router servidor y luego sobreescribirlo con el script correcto del router servidor es lo que me puede estar generando que mi deco cliente no obtenga IP? El fallo creo que está en origen, en el router servidor que es el que configure mal, y no en el cliente. En todo caso, resetearé ambos routers a “fábrica” y comenzaré de 0. Cuando logre la conexión con el tutorial del OP ya me pondré con tus firewall. Muchas gracias. |
27-feb-2026 20:52
#401
|
Ahora el siguiente paso es incluir el firewall de @nlevel Gracias de nuevo a todos! |
08-mar-2026 17:28
#402
|
Hola @bmw528i. Gracias por la ayuda, me fue útil en el pasado. Comentarte que hay nuevas especificaciones del TR3000. Los que tienen número de serie (SN code) TR30002544* y superior (*2545+), usan una nueva flash. Por lo que te agradecería que modificas tu comentario del paso 5 "PARA NO BUSCARLO: https://downloads.openwrt.org/releas...sysupgrade.bin". Está desactualizado. Si la gente flashea el OpenWrt que dices, van a conocer el maravilloso mundo del TFTP: tftpd64, descargar el m_upgrade_TR3000-R47-2.4.22-202511* de la web de cudy, y mierdas varias. Si tienes SN code *2545 o superior, hay que flashearlo con OpenWrt 24.10.5 o posterior. Que lo cojan del selector y menos dramas para todos. |
08-mar-2026 18:09
#403
|
Hola @bmw528i. Gracias por la ayuda, me fue útil en el pasado.
Comentarte que hay nuevas especificaciones del TR3000. Los que tienen número de serie (SN code) TR30002544* y superior (*2545+), usan una nueva flash. Por lo que te agradecería que modificas tu comentario del paso 5 "PARA NO BUSCARLO: https://downloads.openwrt.org/releas...sysupgrade.bin". Está desactualizado. Si la gente flashea el OpenWrt que dices, van a conocer el maravilloso mundo del TFTP: tftpd64, descargar el m_upgrade_TR3000-R47-2.4.22-202511* de la web de cudy, y mierdas varias. Si tienes SN code *2545 o superior, hay que flashearlo con OpenWrt 24.10.5 o posterior. Que lo cojan del selector y menos dramas para todos. |
08-mar-2026 19:19
#404
| Si alguien se instala la OpenWrt 25.12.0 (o posterior?) ya no va con opkg y opkg install de los scripts, va con apk y apk add... hay que hacer un vim /tmp/*.sh y un :wq. Es sencillo, y espero que la gente nos entienda.. sino chapgt xd |
Editado: 09-mar-2026 10:38 -
08-mar-2026 21:44
#405
|
Una vez ya funcional un sistema con servidor-cliente y un Deco en cliente, tengo la duda para tener más Decos (concretamente 2 más, un total de 3) en casa cliente, si: 1) Sacar del puerto Wan del Cudy que ya tengo configurado un switch y de ahí llevármelo a cada una de las habitaciones donde quiera montar otro Deco o; 2) Montar un nuevo sistema con otro Cudy+Deco en cada una de las habitaciones adicionales donde quiera tener un Deco. Como reconozco no ser muy ducho en esto de las conexiones, me surge la duda de qué sistema es "mejor". ChatGPT me traslada opiniones muy dispares en términos de muticast, pero por contrastar con vosotros que realmente domináis! Gracias. |
08-mar-2026 22:10
#406
|
Una vez ya funcional un sistema con servidor-cliente y un Deco en cliente, tengo la duda para tener más Decos (concretamente 2 más, un total de 3) en casa cliente, si:
1) Sacar del puerto Wan del Cudy que ya tengo configurado un switch y de ahí llevármelo a cada una de las habitaciones donde quiera montar otro Deco o; 2) Montar un nuevo sistema con otro Cudy+Deco en cada una de las habitaciones adicionales donde quiera tener un Deco. Como reconozco no ser muy ducho en esto de las conexiones, me surge la duda de qué sistema es "mejor". ChatGPT me traslada opiniones muy dispares en términos de muticast, pero por contrastar con vosotros que realmente domináis! Gracias. ![]() ¿Tienes un switch en casa? Si es así, pruébalo. Si no lo tienes, compra otro cudy. Lo digo porque OpenVPN en modo TAP no hace igmp_snooping. Igual que se ha hablado en este hilo que no se deben clonar clientes y que todos esos clientes usen un único tap/tap0 del servidor, no se deben enchufar 2 decos a un único cliente. Así provocarás replicación masiva. En otras palabras, la teoría dice que si tienes un único cudy cliente, cuando tus 2 decos enchufados a ése cliente quieran ver diferentes canales, estarás haciendo que la CPU de tu cliente esté "multiplicando streams"... pero en éste hilo se ha comentado que en la práctica: el cudy va sobrado haciendo eso en servidor y cliente(s), así que si tienes un switch, hazlo. router de tu casa > cudy > switch > los 2 decos. (si haces esto, no se te ocurra meter otro cliente, en otra casa, también por tap/tap0 porque entonces sí que vas ver los problemas de "multiplicar" y no "sumar") Si no tienes un switch, yo no me lo compraría sólo por eso. Además de que el Cudy vale 40e +/-, y tener 2x "Cudy-Deco" es perfecto, porque te lo puedes llevar por ahí, y en esa casa dejas el otro Cudy-Deco. Eso sí... ahí empieza tu fiesta con el chatgpt para crear en el servidor donde ya tienes el tap/tap0 un nuevo tap2, configurar el .ovpn, abrir otro puerto en servidor, etc. |
Editado: 08-mar-2026 22:15 -
09-mar-2026 21:34
#407
|
Trato de darte mi opinión hasta que los gurus te ayuden
![]() ¿Tienes un switch en casa? Si es así, pruébalo. Si no lo tienes, compra otro cudy. Lo digo porque OpenVPN en modo TAP no hace igmp_snooping. Igual que se ha hablado en este hilo que no se deben clonar clientes y que todos esos clientes usen un único tap/tap0 del servidor, no se deben enchufar 2 decos a un único cliente. Así provocarás replicación masiva. En otras palabras, la teoría dice que si tienes un único cudy cliente, cuando tus 2 decos enchufados a ése cliente quieran ver diferentes canales, estarás haciendo que la CPU de tu cliente esté "multiplicando streams"... pero en éste hilo se ha comentado que en la práctica: el cudy va sobrado haciendo eso en servidor y cliente(s), así que si tienes un switch, hazlo. router de tu casa > cudy > switch > los 2 decos. (si haces esto, no se te ocurra meter otro cliente, en otra casa, también por tap/tap0 porque entonces sí que vas ver los problemas de "multiplicar" y no "sumar") Si no tienes un switch, yo no me lo compraría sólo por eso. Además de que el Cudy vale 40e +/-, y tener 2x "Cudy-Deco" es perfecto, porque te lo puedes llevar por ahí, y en esa casa dejas el otro Cudy-Deco. Eso sí... ahí empieza tu fiesta con el chatgpt para crear en el servidor donde ya tienes el tap/tap0 un nuevo tap2, configurar el .ovpn, abrir otro puerto en servidor, etc. |
09-mar-2026 22:55
#408
|
Sinceramente yo no he tenido problemas utilizando un único servidor/cliente. De hecho mi servidor es una máquina virtual de OpenWRT en Proxmox y los clientes igual. Lo que hago en cada vivienda es redirigir la salida del tap0 del cliente hacia una VLAN y luego conecto cada deco a un switch gestionando al que le asigno esa VLAN al puerto. Lo tengo así hace años y sin problemas. Además de los decos, en esa VLAN tengo todas las cámaras ip de mis otras viviendas y funciona todo sin problemas.
¿Pero dónde estás aplicando el tag de las VLANS, en el router cliente hacia los decos o es un VLAN que viaja por el túnel? |
10-mar-2026 00:16
#409
| El tap0 que llega al cliente en la otra vivienda lo añado a un bridge en el que está la VLAN y esta sale hacia mi red local. Así que todo lo que quiero que viaje por la VPN lo añado a esa VLAN. |
10-mar-2026 00:53
#410
| Si he entendido bien, usas un solo server OpenVPN con varios decos... Y no ves en el router que hace de server cómo duplicas el tráfico multicast?? |
10-mar-2026 01:26
#411
| En mi vivienda principal tengo el server, en las otras vivienda en los routers clientes asigno tap0 a una VLAN. A esa VLAN conecto todo lo que quiero que esté en la red local de mi vivienda principal. En el caso de los decos, a más decos que conecto más tráfico veo, pero no que se vaya duplicando con cada deco que conecto, simplemente veo más tráfico conforme los voy encendiendo. |
10-mar-2026 09:17
#412
|
En mi vivienda principal tengo el server, en las otras vivienda en los routers clientes asigno tap0 a una VLAN. A esa VLAN conecto todo lo que quiero que esté en la red local de mi vivienda principal. En el caso de los decos, a más decos que conecto más tráfico veo, pero no que se vaya duplicando con cada deco que conecto, simplemente veo más tráfico conforme los voy encendiendo.
Ya nos cuentas. |
11-mar-2026 13:19
#413
|
Pues he hecho esto, tailscale en la rpi como exit node, tailscale en mi TV Android y con la app de movistar ya puedo ver la TV como si estuviera en casa. Proceso ultra sencillo, no había usado Tailscale antes y la verdad que es una pasada, y se pueden añadir varios usuarios.Os lo recomiendo a todos aquellos que no os queráis complicar demasiado la vida. También se puede compartir Netflix, etc.
|
11-mar-2026 14:28
#414
|
Buenas. Antes de meterme a trastear, quería preguntaros a los que más controláis si sería factible usar como servidor OpenVPN una Raspberry Pi que ya tiene un servidor Wireguard y otras cosas como Home Assistant y Plex, sin tener que usar el adaptador USB a ethernet y sin que el resto de servicios se vean perjudicados. Pregunto ya que según Gemini si que se podría, pero como a la primera no suele atinar y hay que modificar y rectificar muchas de las que dice, por no perder el tiempo. La idea es usar de cliente un Cudy WR3000 V1 con OpenWrt con el que he estado trasteando para otras cosas y ya me ha picado el gusanillo de hacer funcionar un deco de forma externa. Gracias y salu2. |
15-mar-2026 23:17
#416
|
Buenas. Antes de meterme a trastear, quería preguntaros a los que más controláis si sería factible usar como servidor OpenVPN una Raspberry Pi que ya tiene un servidor Wireguard y otras cosas como Home Assistant y Plex, sin tener que usar el adaptador USB a ethernet y sin que el resto de servicios se vean perjudicados.
Pregunto ya que según Gemini si que se podría, pero como a la primera no suele atinar y hay que modificar y rectificar muchas de las que dice, por no perder el tiempo. La idea es usar de cliente un Cudy WR3000 V1 con OpenWrt con el que he estado trasteando para otras cosas y ya me ha picado el gusanillo de hacer funcionar un deco de forma externa. Gracias y salu2. |
15-mar-2026 23:34
#417
|
A ver si me pongo y si me surgen dudas ya os consulto por aquí. Gracias. Salu2. |
17-mar-2026 10:30
#419
| Mal, va muy justo. Algunos canales no van del todo. Busca "opal" en el hilo y tienes opiniones. |
23-mar-2026 22:40
#420
|
Actualizo con un par de cuestiones: he notado que en canales y en partidos de alta demanda, ya tenga encendido el deco en casa servidor o no (es decir; no agrava el problema el hecho de que ambos decos estén encendidos, o eso creo) se producen pequeñas pixelaciones. No muy habituales y no muy periódicas, pero ocurren de vez en cuando a lo largo del partido. También es cierto que en casa servidor lo había notado alguna vez antes de montar el servidor-cliente; creo que es algo inherente a Movistar; pero por confirmar con vosotros si a alguno más le pasa. En un partido de champions puede ocurrir unas 5-6 veces; no se corta ni llega a pararse, y el audio continúa sin salto, dura menos de 1 segundo, pero ocurre una pequeña pixelación o blurring. Por otro lado, he probado a conectar el router cliente a un switch, al que he conectado a su vez 3 decos y ha funcionado perfectamente; tanto emitiendo el mismo canal como canales diferentes. No he notado nada raro y la CPU del router cliente funcionando de manera muy solvente (Cudy TR3000) sin bajar del 65% en router cliente. |
