Foro
Buenas pitxanegra
Prácticamente todo lo que expones tiene sus matices y sus explicaciones. Si no te importa, te contesto cada punto explicando razones/soluciones/matizaciones:
- Restricciones en la Configuración Avanzada
Simplemente no es cierto. Movistar "obliga" al fabricante a exponer una serie de funcionalidades, y de ahí nace la interfaz mhs, la simplificada si quieres llamar así. La interfaz Avanzada es cosa de Askey, y por eso es tan diferente a la de Mitrastar. Es cierto que Movistar puede decirle que incluso en esa existan o no ciertas opciones. Pero la mayoría son decisiones de Askey, que simplemente a Movistar le es indiferente. Dices que cada vez ves menos opciones... ¿cuales exactamente? Tengo el mismo modelo, y si bien no digo ni mucho menos que sea perfecto, quitando dos o tres detalles no veo ninguna ausencia de importancia, lo más "ausente" podríamos llamar más avanzado y se puede configurar por SSH - Imposibilidad de desactivar Band Steering/SSID
Esto lo expliqué en el post que hice. Estamos en WIFI7, y una de sus características estrellas es MLO, que requiere fundamentalmente BandSteering/SSID único. No me gustan los SSID únicos, aconsejo SIEMPRE separarlos para tener mayor control. MLO es algo formidable en entornos ideales y con todos los dispositivos WIFI7, en una amalgama de dispositivos es mucho mejor redes separadas. ¿Entonces? Pues que es un problema de como explicarlo/exponerlo. Estos equipos tienen que ser "buenos" para el 99% de usuarios que no tienen la menor idea que es MLO, BandSteering... Ya tienen ahora mismo bastantes advertencias diferentes e los ajustes WIFI, imagina tener que añadir otras pocas para explicar que si deshabilitas BandSteering de facto dejas de poder usar MLO, y algunas funcionalidades Mesh que tiene el Router. Ojo, que abogo por ponerlo y que la lógica interna reconfigure los ajustes WIFI7 para permitirlo. Pero tiene su explicación. Otra cosa es que el enfoque que han tomado sea mejor/peor.
Aun así se pueden separar de un modo relativamente sencillo haciendo trampa, aunque no es lo más bonito del mundo, y no tienes que "jugar" con botones. Simplemente deshabilita la primera red del AP de 2.4GHz, y habilita el segundo AP de la red de 2.4Ghz, al que le pones el nombre que quieras y tomas la precaución de deshabilitar el AP Isolation. Simple y llanamente. - Imposibilidad de ajustar el protocolo de seguridad WPA
No puedo decir que tengas razón. He podido configurar sin ningún tipo de problema tanto WPA2-PSK únicamente, como WPA3-SAE únicamente. No tengo claro el problema que citas... y lo he podido hacer tanto por Web como por SSH. Además, por otro lado dices: "...encriptación distinta a WPA2/WPA3. Tengo dispositivos que con esa configuración no se conectan y solo lo hacen con WPA2", lo cual invalida totalmente tu punto. Cuando la seguridad está en WPA2/WPA3, signfica que está en modo mixto, permite conectarse a dispositivos tanto por WPA2-PSK como por WPA3-SAE. Si fuerzas a usar WPA2-PSK lo único que haces es que no se pueda usar WPA3-SAE, lo que sí es una degradación de seguridad, y rompe automáticamente funcionalidades de WIFI7, que obligatoriamente requieren WPA3-SAE. - Limitaciones en el control de DNS
No tengo claro a que limitación te refieres, no existe ningún tipo de limitación. Puedes asignar por DHCP las DNS que te den la real gana como siempre ha pasado, e igualmente puedes cambiar las propias DNS que usa internamente el Router... no existe ningún tipo de cambio en ello, ni son ajustes escondidos, ni son ajustes raros ni nada por el estilo. De hecho uso mi propio servidor DNS sin ningún problema. - Gestión de canales WiFi
Ningún sistema de canal automático tiene sentido a día de hoy si quieres un buen control. Si lo pones en automático aplica reglas obviamente fijas y estrictas. A eso tienes que sumarle que si usas un bloque DFS, el Router por ley salta, quieras o no quieras. Y esto cobra especial interés y sentido en la banda de 5GHz, puesto que este Router por defecto usa anchos de 160Mhz, lo que implica que por defecto da exactamente igual el canal que pongas, va a saltar antes o despúes. Esto se debe a que únicamente existe un bloque no DFS, es decir, que no salte. El problema es que es un bloque de 80Mhz, con lo que si el Router emite en 160MHz va a saltar quieras o no quieras antes o después. Y esto es por ley - Filtrado MAC
Exacto, fue eliminado GRACIAS A DIOS!!. El filtrado MAC jamás ha sido una funcionalidad de seguridad, y la mayoría de personas la usaban para ello, y esto es un error enorme, porque se da la falsa sensación de seguridad. Movistar prefirió, y en este caso lo aplaudo, a usarlo de un modo alternativo, a modo de un control parental simple. Ahí sí tiene cierto sentido su uso. Y para ello es necesario una interfaz más visual, que sea sencillo seleccionar un dispositivo para bloquearlo temporalmente, permitirlo etc etc. Y no soy fan de la App, ni tampoco creo que sea un buen modo de control parental teniendo otras opciones mucho mejores, pero entiendo que pueda tener cierta utilidad. Ahora bien, en cuanto a seguridad se refiere no vale absolutamente nada. No es otra capa de seguridad como dicen algunos, su valor es literalmente menor que cero, porque es contraproducente. - No te respetan muchos de tus ajustes
Los ajustes se respetan el 99% de las veces. Es cierto que en alguna actualización puede que de la sensación de que no se respeten, pero no es eso lo que pasa realmente. Al estar aun por pulirse, es normal que ciertas variables cambien. Te pongo un ejemplo muy simple para que lo entiendas. Imagina que con la 2.6 cuando configuras WPS = disabled, el archivo de configuración guarda algo como wifi_wps = disabled. Ahora imagina que sacan la 2.11 y ciertos ajustes se han reestructurado, cuando arranca el Router por seguridad limpia cualquier variable/valor erroneo, y es que ahora wifi_wps puede que no exista, con lo que desaparece y se setea su valor original, que ahora a lo mejor se guarda como wifi0 = disabled. Este comportamiento es totalmente normal en cualquier Router que puedas encontrar en el mercado. En algunas ocasiones es habitual incluso que te obliguen quieras o no quieras a tener que hacer un reset, por las mismas razones. - Inestabilidad en la banda de 5GHz
Aquí habría que definir inestabilidades. No es que se tengan inestabilidades, es que partimos de la base de que WIFI es inestable por propia naturaleza. Sin más. No he visto desaparecer la banda de 5Ghz en ningún solo momento, ni otro comportamiento anómalo fuera de la naturaleza WIFI general. Es cierto que mientras que las redes están unidas bajo el mismo SSID los dispositivos pueden tener muchas muchas veces comportamientos anómalos, efectos habituales de tener bandSteering, y más aun ahora si son WIFI7 los dispositivos y pretenden usar MLO. Pero nada más raro de lo habitual, la verdad, no he notado ninguna degradación o rareza. - Problemas con el Firmware de 10Gb y WiFi 7
No sé que problemas son esos la verdad. Es cierto que teóricamente el Router por XGSPON puede llegar a una cuota cercana a los 10Gbps (no llega), y es obvio que si uno intenta una velocidad sostenida y larga, puede tener problemas... pero fundamentalmente porque son tasas tan altas que cualquier mínima fluctuación (por cable, por WIFI, de la propia fibra, del dispositivo... ) puede ocasionar un parón de pronto. Ahora bien, no de tener que reiniciar. No he reiniciado a día de hoy una sola vez el HGU7 por motivos obligados, siempre ha sido a voluntad y razones concretas y obvias. Ahroa bien, no dudo ni mucho menos que aun tengan que pulir la firmware y que puedan salir algunos bugs y problemas a lo largo de los meses, como ha pasado con todos los HGU anteriores. - Calor excesivo y degradación
Esto es cierto y no. Es cierto que el Router (este y cualquier otro) pueden generar a día de hoy tasas enormes de calor. Queremos dispositivos cada vez más potentes, rápidos, eficientes... señores, estamos hablando de un dispositivo que es capaz de mover cerca de 10Gbps!! Sabéis que es eso??? Eso es más o menos como que te digo yo... más de 400 personas en tu casa viendo Netflix en 4K en dispositivos diferentes sin un solo parón. Gracias a la miniaturización podemos fabricar cada vez chips/SoC más eficientes, más pequeños... gracias a eso mismo podemos seguir aumentando las prestaciones y rendimiento sin fundir nada. Ahora bien, que no fundamos nada no significa que se puedan mantener unos cómodos 20º. Además, otra cuestión fundamental... ¿estarías dispuesto a que tu Router hiciese ruido? La inmensa mayoría te dirían que que nueva locura es esa. ¿Pero entonoces como diablos quieres disipar el calor? Un PC requiere ventilación activa sobre un enorme radiador o lo fundes. Aquí no se llega a ese extremo, se tienen radiadores de buen tamaño, pero se intenta usar ventilación pasiva para evitar ruidos y piezas móviles que se desgastan. ¿Por qué te crees que es en vertical?
Aun así, el calor no es más que en otros modelos, está dentro de lo normal. Ahora mismo mi unidad por ejemplo: wifi 47, wifi_plus 39,main_soc 56.7. Temperaturas bastante comedidas, mi propio Router está ahora mismo WIFI a unos 50-60º. No es un error de diseño, sino física básica. Tienes dos opciones... o te beneficias en cada salto tecnológico de la mayor integración de componentes para bajar el consumo y generar menos calor, o lo usas para mejorar el rendimiento y mayores prestaciones. No puedes tener ambas. Y esto se cumple para cualquier Router. Y no, no hay degradación que podamos siquiera medir. Sí, en altas cargas la temperatura va a subir, y sus componentes están diseñados para ello. No es lo más ideal, es que no hay otra solución, es como funcionan los dispositivos a día de hoy. Solo el Switch interno debe de generar una cantidad de calor terrible al mover cargas enormes de datos.... - Actualizaciones forzosas sin aviso
Sí, claro, el equipo es del operador, y el operador se tiene que asegurar que sus equipos están actualizados. Esto no es un error ni un problema, al contrario. Si yo tuviese que tomar las decisiones en la empresa sobre que políticas aplicar y cuales no, te aseguro que esta sería así. Los equipos son de ellos, la red es de ellos, y es de ellos la responsabilidad de, en la medida de lo posible, asegurarse una seguridad. Si no fuese así, y pongamos por ejemplo que en la versión 2.6 se descubre u exploit malicioso que puede permitir el acceso no autorizado a cualquiera por WIFI.... que pasaría? De quien sería la responsabilidad? De Movistar que a lo mejor sacó la actualización hace días o del usuario que no la instaló? Sí no fuerzas las actualizaciones, se podría demandar incluso a Movistar por no tomar las medidas adecuadas. Otra cosa diferente es que tú, personalmente y de forma voluntaria, quieras evitar esos comportamientos expresamente. Hazlo, pero entonces el ISP se puede lavar las manos, es como si usas tu propio Router. Hazlo si quiere, pero te expones a las consecuencias tú. Puedes deshabilitar TR069 si quieres... pero si tienes problemas pues... Respecto a lo que dices de cambios en la configuración, lo he explicado previamente
Por cierto, además, un error nada pequeño de concepto: "...A mi particularmente no me gusta que nadie me enrede en mi router sin mi permiso". Es que, me temo decirte, que no es tu Router, es el de ellos. Si quieres un Router propio vas al mercado y te compras el que tú quieras. Pagues o no pagues por el HGU, este pertenece a Movistar y lo tienes únicamente en régimen de uso perpetuo mientras mantengas el servicio. Si te vas o lo cambian, se lo llevan, es de ellos. - configuración de ciertas reglas Firewall
Sí y no. Aquí hay una mezcla. De nuevo, su Router sus normas. Nadie te obliga a usar su router, puedes usar tu propio Router si así lo quieres. Dado que es su propio Router, requieren como es natural para poder asegurar al 99% de los clientes un buen servicio. Esto implica no solo acceso por TR69 cliente/servidor, sino reglas que puedan permitir teóricamente accesos por Web/SSH si lo necesitasen. ¿Esto está bien o está mal? Las reglas que usan son exclusivamente para dar acceso a los equipos de gestión y soporte, nada más. Esto no es un problema de seguridad de ningún tipo, es una salvaguarda que ponen.
Ahora bien, si bien entiendo que es totalmente normal y natural que usen dichas reglas, eso no exime que Askey (y esto es fallo de Askey) no exponga un Firewall en la interfaz Web. Y no precisamente por lo comentado anteriormente, y que el usuario borre o no borre las entradas que sea, sino para poder configurar sobre todo reglas para IPv6 por ejemplo.
Por qué esto no es algo "dramático"? Bueno, porque Askey/Movistar en este caso han decidido que como son funciones altamente avanzadas (puesto que al 95% les da exactamente igual y a otro 4% que quieren control total usa su propio Router), también permiten esos borrados o ediciones de todos modos, aunque de un modo algo más manual por SSH.
Para mi el gran problema de esto no es para nada esas reglas que citas, eso es humo realmente, sino potencialmente un problema para cuando se despliegue (si se hace en algún momento) oficialmente Pv6 y deje ser una beta. - banda de 6Ghz?
Este es un tema escabroso, y es muy posible que no la veamos nunca por la mayoría de los ISP. Que ha pasado con ella? Pues no pocas cosas... no es un solo motivo, son muchos
-Precio: El hardware es bastante más caro... y solo el HGU7 ya puede tener un coste de mercado aproximado de unso 300-400€
-Europa: En Europa las teleco aun están discutiendo que hacer con la banda de 6GHz, ya que es una banda suculenta para servicios de redes móviles 5G/6G. Ya de hecho no se puede usar toda la banda de 6Ghz, ahora mismo en Europa solo se puede usar la mitad, con lo que prácticamente puedes decirle adiós a emitir en anchos de 320MHz. Y dependiendo de la presión y el uso es posible que terminen devorándola por completo
-Soporte Marginal: A día de hoy, si bien la mayoría de dispositivos "tops" son WIFI7, el soporte para la banda de 6GHz es muy muy reducido.
-Utilidad Entredicha: Y llegamos al punto principal. Realmente la banda de 6Ghz es en esencia un reclamo de marketing sin prácticamente uso real. Física básica de nuevo: Mayor frecuencia, menor penetración de la señal. En la banda de 5GHz se permitió duplicar la potencia de emisión frente a la banda de 2.4GHz, y aun así perdemos de forma fácil más de un 20% de señal, pq no es suficiente esa duplicación para mantener la penetración e intensidad. Con la banda de 6GHz es aun mucho peor, porque la potencia de emisión es la misma! Eso significa que si la banda de 5GHz ya tenía menos penetración/alcance, la banda de 6GHz te va a permitir entre un 10-30% aun menor respcto a la de 5GHz..
Es decir, ya no solo es que el alcance relativo (en espacio abierto) la banda de 6GHz sea casi la mitad del que te va a dar la banda de 2.4GHz, es que la penetración que tiene es muy inferior, hasta el punto que prácticamente cualquier muro la para en seco, con que pongas una o dos paredes de pladur se acabó el juego.
En esencia, la banda de 6Ghz donde brilla es en espacios muy muy cortos, generalmente la misma habitación. Y francamente, para eso, usa un cable, que es infinitamente mejor. Con que estés en la habitación de al lado ya estará sufriendo enormemente. Es simplemente una realidad física. Simplemente eso no te lo dicen los fabricantes :) - Imposibilidad de un Modo Monopuesto (Bridge) Real
Esto es totalmente incorrecto. Primero y principal, el modo Monopuesto no es un Bridge real. El Modo monopuesto es un invento propio de Movistar precisamente para lo contrario que estás diciendo!! Para facilitar que prácticamente cualquier Router que quieras poner puedas ponerlo. Movistar habría podido en vez de usar un modo "Monopuesto" usar un "Bridge" Real? Sí, pero entonces únicamente podrías conectar equipos muy específicos que permitiesen configurarse para poder gestionar 3 WAN por VLAN independientes, cada una con sus historias. El modo monopuesto soluciona esto totalmente. haciendo que únicamente requieras un Router que pueda levantar la sesión PPPoE, nada más.
Eso significa, como dices, que el HGU siga manteniendo la gestión de las VLAN VoIP y la VLAN IPTV. Exactamente, de hecho esa es la idea, para que tu propio Router no tenga que gestionarlas, porque eso limitaría enormemente los dispositivos posibles. Pero es que esto no es ninguna limitación!! Dices:
"...un usuario avanzado, que quiere usar su propio firewall o router neutro, este equipo (y otros mas antiguos) se convierten en un obstáculo técnico. Esto genera problemas de doble NAT y latencias innecesaria"
Es que eso es totalmente falso. No existe ningún tipo de obstáculo técnico para que puedas usar tu propio equipo, no existe ningún tipo de limitación, y mucho menos existe ningún problema de doble NAT ni de latencia. Yo uso siempre como principal mi propio Router. Tengo el HGU7 en monopuesto. ¿Me puedes explicar que limitación tengo? Toda mi red principal está gestionada y controlada perfectamente por mi propio Router, si doble NAT y sin historias, mi Router levanta el cliente PPPoE. Del mismo modo, aunque el HGU gestione la VLAN VoIP e IPTV, puedo perfectamente conectar a mi propio Router también cualquier Deco, Softphone IP sin problema alguno, o literalmente lo que me de la real gana, que funciona a la perfección. Que las dos VLAN estén levantadas en el HGU, eso no es ninguna limitación de ningún modo, no hay nada que impida que configures tu propio Router para hacer uso de ellas, y si existe es por falta de conocimientos o por mala elección de hardware, por nada más.
En cualquier caso, es infinitamente razonable y lógico que exista un modo Monopuesto, a no un Bridge real. El primero hace automáticamente que el 99% de los Router del mercado puedan sin problema gestionar Internet, el segundo posiblemente menos de un 10%. Si tenemos en cuenta que por otro lado el uso de monopuesto no implica absolutamente ninguna limitación real autoimpuesta... pues es obvio cual es el modelo a usar. De nuevo, si fuese yo quien tomase dichas decisiones, no es algo que cambiaría, me parece un equilibrio muy lógico. El que quiera usar su propio equipo que lo use, sin más, es de suponer que si quiere usar su propio Router pq como dices es un usuario avanzado por ejemplo, podrá y sabrá configurar su propio equipo para el escenario que desea. ¿No te parece?
De todos modos, si hay algo concreto que se me haya escapado y que veas que realmente te es un problema "importante", lo vemos. Después de muchos días ya con él y de exprimirlo todo lo que que podido y más, no veo grandes problemas salvo las sugerencias que hice en otro hilo y sus soluciones alternativas. No digo que la firmware sea perfecta ni mucho menos... es más, me hace gracia porque los problemas realmente importantes que tiene te han pasado desapercibido!! Claro que tiene errores que espero solucionen, pero la mayoría de las cosas que se objetan aquí, o no son correctas o tienen sus explicaciones. Otra cosa es que estemos más o menos de acuerdo con Movistar de algunas políticas que puedan tener con ciertos asuntos, pero en general... no veo ningún drama de importancia
Saludos
Buenas tardes.
Sin ánimo de crear polémica, pero me creo en el derecho de responder.
Esta es una respuesta clásica, de un perfil técnico de Nivel 2 que intenta "educar" al usuario, tratándolo de entusiasta, pero ignorando que el HGU7 (Askey RTF8316VW) es, por definición, un equipo con un firmware "extremadamente capado" y a medida de movistar (no del usuario final avanzado) y con comportamientos erráticos en entornos profesionales, o de power user.
Créeme que le agradezco la detallada respuesta técnica. No obstante, tras analizar sus puntos, observo que se confunde la "decisión de diseño del fabricante" con la "necesidad operativa del cliente". El hecho de que un comportamiento tenga una explicación teórica (como el estándar WiFi 7 o la normativa DFS) no justifica la eliminación de controles manuales en la capa de gestión.
A continuación, rebato los puntos clave:
1. Gestión de DNS y soberanía de red:
Usted, entiendo que afirma que no hay limitaciones. Sin embargo, el router intercepta o dificulta la propagación de DNS locales en ciertos escenarios de tablas de rutas internas, especialmente cuando se intenta forzar un filtrado vía Pi-hole o AdGuard Home a nivel de interfaz WAN/LAN de forma persistente sin que el servicio de gestión remota de Movistar (TR-069) revierta cambios en caliente. Si la interfaz avanzada es "cosa de Askey", Movistar, como proveedor del servicio, "debe garantizar" que el firmware no sobreescriba configuraciones de usuario mediante scripts de aprovisionamiento automáticos.
2. Imposibilidad de Modo Bridge / Módem Puro (Punto Crítico):
Este es el núcleo de mi reclamación que su respuesta obvia. De él no ha comentado absolutamente NADA. ¿Motivo?. ¿Tengo demasiada razón?
El HGU7 actúa como un secuestro técnico de la línea. No permite un Modo Bridge (Bridge específico de la VLAN 6) funcional y estable que delegue la gestión de la sesión PPPoE, el NAT y el enrutamiento a un firewall/router profesional de terceros (tipo Ubiquiti, Mikrotik o OPNsense).
- El modo "monopuesto" de estos equipos sigue manteniendo una tabla de NAT activa, y una capa de software que degrada el rendimiento de la línea de 10Gbps.
- Para un entorno de alto rendimiento, el HGU7 actúa como un "cuello de botella" propietario. Exijo A MOVISTAR una solución para un bypass total de la ONT integrada sin sufrir la inestabilidad que presenta el firmware actual al intentar bridgear la VLAN de datos. Exijo la capacidad de realizar un bridge total de la VLAN 6 para delegar la sesión PPPoE a mi propio hardware.
3. WiFi 7, MLO y Band Steering:
Su argumento sobre MLO y el 99% de los usuarios es una falacia de autoridad. Un usuario avanzado requiere determinismo en la red.
- Forzar un SSID único basándose en el estándar WiFi 7, impide optimizar dispositivos IoT (2.4GHz) que sufren desconexiones por intentos fallidos de negociación en bandas superiores.
- La solución de "hacer trampa" habilitando un segundo AP y deshabilitando el primero, es un workaround (parche) inaceptable en un equipo de esta categoría. La interfaz "debe permitir" la segregación nativa de bandas por radiofrecuencia (2.4, 5 y 6GHz) para gestionar el espectro de forma manual y evitar el "stuttering" en dispositivos no compatibles con MLO.
4. Seguridad WPA y protocolos de legado:
No recuerdo ahora donde era pero había una opción capada respecto a poner el modo de encriptación que yo considere oportuno. Espero que solo haya sido un bug del firmware y lo hayan solucionado.
Aun así, el problema no es el modo mixto (WPA2/WPA3), sino la negociación de handshakes en el firmware de Askey. He detectado que, en modo mixto, el router falla al asignar claves temporales (PTK/GTK) a dispositivos que estrictamente requieren WPA2-AES, resultando en bucles de autenticación. La capacidad de "forzar" un protocolo por SSH no es una solución válida para un producto comercial. Debe ser una opción persistente en la GUI. ¿o no?
5. Gestión de Canales y DFS:
Entiendo (en parte) la normativa legal sobre DFS. Sin embargo, el router presenta una latencia excesiva en el escrutinio de canales (Channel Availability Check). En un entorno denso, el algoritmo de selección automática del RTF8316VW opta por canales con alto nivel de ruido en lugar de permitir un bloqueo manual en canales fijos de 80MHz para evitar el salto constante de frecuencia, lo que provoca micro-cortes en sesiones de streaming y gaming. Un usuario "normal" que solo usa el router para "Guasapear", pues no lo va a notar, ¿VErdad?. Pero los que usamos internet para algo mas que comprar en temu o aliexpress, si que lo notamos, y hasta nos es muy muy molesto.
6. Estabilidad de Firmware y Calor:
Usted admite (entiendo no no del todo), que el equipo genera altas tasas de calor. En electrónica, sobre todo de red, y mas en entornos de radiofrecuencia, el calor es sinónimo de degradación de la relación señal-ruido (SNR SINAD) y aumento del jitter. Y sigo recordando que España, es un país cálido mediterráneo. Si el hardware no es capaz de mantener una tasa de 10Gbps sostenida sin fluctuaciones, estamos ante un déficit de diseño térmico o de capacidad de proceso del SoC Broadcom/Askey. Y que solución le damos?, Ponemos un A.A. en la habitación?, o las llaves encima del router para que las antenas hagan de plano de tierra y enfríen la carcasa?
7. Desdén técnico sobre el Filtrado MAC:
Usted afirma que el filtrado MAC es "inservible" y "contraproducente". Esta es una visión reduccionista.
Si bien no es una medida (de acuerdo en parte) de seguridad infranqueable, contra un atacante experto (debido alspoofing), es una capa de control de acceso perimetral básica y efectiva en entornos domésticos para:
- Evitar la asociación automática de dispositivos conocidos pero no deseados en bandas específicas.
- Servir como inventario de activos autorizado (White List), algo esencial cuando se gestionan más de 30-40 nodos IoT.
- Eliminar una funcionalidad estándar en cualquier router del mercado desde hace 20 años bajo el pretexto de "seguridad falsa" es, en realidad, una claudicación del fabricante por no querer gestionar tablas de direcciones en memoria. Sustituirlo por una App móvil es trasladar el control del hardware local a la nube de Movistar, algo que vulnera la autonomía técnica del cliente. Otra cagada mas.
Conclusión:
La respuesta recibida justifica las carencias del equipo basándose en la "facilidad de uso para el usuario básico/medio". Yo, como cliente de un servicio premium de 10Gbps, requiero un equipo que se comporte como un puente transparente, o que permita una gestión profesional total y no "a medias" según le venga en gana a movistar.
Solicito la escalación de este caso para:
- Proveer al Askey de un método de Modo Bridge real (transparencia de Capa 2).
- O bien, sustitución por una ONT externa compatible con XGSPON para eliminar la [....] capada Askey, de la ecuación de enrutamiento.
Un saludo
- Técnico-Movistar08-04-2026Responsable Técnico
Hola pitxanegra
Como no hemos recibido más comunicaciones por tu parte, creemos que ya no necesitas más ayuda desde el foro. Si más adelante tienes alguna otra consulta nos lo comunicas y estaremos encantados de ayudarte en la Comunidad.
Un saludo, Sebastián.
- Técnico-Movistar06-04-2026Responsable Técnico
Hola pitxanegra
No hemos recibido más comunicaciones de tu parte. No dudes en contactarnos nuevamente si tienes alguna consulta o inconveniente; estaremos a tu disposición para ayudarte.
Muchas gracias por participar en la Comunidad.
Un saludo, Tatiana.
- Técnico-Movistar04-04-2026Responsable Técnico
Hola pitxanegra
Agradecemos a eruizm por su aporte respecto a las temperaturas en los equipos y la importancia de que tengan una buena ventilación.
No hemos recibido respuesta por tu parte. No dudes en contactarnos nuevamente si tienes alguna duda o consulta relacionada con la información proporcionada por otros usuarios anteriormente. Es importante para nosotros saber si lograste obtener una respuesta adecuada a las funciones que mencionabas. De igual manera, te pedimos disculpas por los inconvenientes y te aseguramos que nuestra prioridad es siempre ofrecer un servicio de la mejor calidad posible. Por otra parte, si consideras que tu consulta ha sido resuelta, te agradeceríamos que, en el hilo que has abierto, pulsaras el botón "Marcar como solución" en el post que resolvió tu caso. Es importante para nosotros confirmar que tus consultas han quedado resueltas y, para otros usuarios, estas respuestas pueden ser útiles para resolver dudas similares.
Muchas gracias por participar en la Comunidad.
Un saludo, Tatiana.
- Técnico-Movistar30-03-2026Responsable Técnico
Hola pitxanegra
En relación con tu pregunta, varios usuarios han compartido varias respuestas en los mensajes anteriores que pueden ayudarte a resolver la duda planteada. Te invitamos a revisarlas y, si necesitas alguna aclaración adicional o tienes más preguntas, por favor háznoslo saber. Estamos aquí para ayudarte.
Un saludo, Sebastián.
- Theliel25-03-2026Yo probé el VDSL
Buenas pitxanegra
Con gusto contesto a tus puntos, la mayoría de ellos sin ningún tipo de fundamento:
1. Gestión de DNS y soberanía de red:
Esto no es correcto. De ninguna manera. Yo mismo uso un servidor PiHole en local, y jamás he tenido un solo problema con ningún HGU, ni en Monopuesto ni en modo nominal. Es cierto que Movistar tiene un servicio de Seguridad Integrada (deshabilitado por defecto) que puede interceptar peticiones DNS para filtrados DNS básicos de toda la vida (seguridad, contenido, etc). Pero quitando esto, y que repito no está habilitado por defecto ni use usa, ni Movistar ni el Router interceptan ninguna petición DNS. Puedes usar sin la menor complicación el servidor DNS que te de la gana, sea un servidor externo, sea un servidor interno (PiHole), puedes modificar tanto las DNS del propio Router como las que asigna por DHCP.
2. Imposibilidad de Modo Bridge / Módem Puro (Punto Crítico):
Creo que lo había explicado, pero por si se me quedó en el tintero, te respondo con gusto. Dudo enormemente que Movistar vaya a implementar algo que ya tiene implementado de un modo mucho más lógico y coherente. No tendría ningún tipo de sentido permitir por un lado un modo "Monopuesto" y por otro lado un modo Bridge Real. La razón de que Movistar optase por el modo Monopuesto, como ya he dicho, es precisamente para poder permitir que el usuario pudiese usar prácticamente cualquier Router que quisiese. Si Movistar implementase un modo Bridge real, el número de usuarios que se beneficiarían sería dentro del 5% que a lo mejor usa su propio Router, un 10% de ese 5% o menos. Si pones todo ello en la balance es obvio que sistema escoges: Monopuesto. ¿Por qué? Porque no tiene ninguna limitación con respecto al Bridge real, y permite en esencia usar el 99% de los Router del mercado. Dices, y cito textualmente:
"No permite ... que delegue la gestión de la sesión PPPoE, el NAT y el enrutamiento a un firewall/router profesional de terceros"
Totalmente falso, el modo Monopuesto lo hace. En Monopuesto delegas la sesión PPPoE, la gestión de Internet pasa de forma integral a tu propio Router, que doy por sentado que hará NAT a su vez. Lo único que hace es quitar la necesidad de tener que lidiar con tres interfaces etiquetadas por VLAN.
Por otro lado esgrimes:
"El modo "monopuesto" de estos equipos sigue manteniendo una tabla de NAT activa, y una capa de software que degrada el rendimiento de la línea de 10Gbps .... Para un entorno de alto rendimiento, el HGU7 actúa como un "cuello de botella" propietario..."
De nuevo, totalmente falso e infundado. Sí, claro que el HGU sigue manteniendo una tabla NAT, dado que la red del HGU no desaparece. El no-problema de esto es que dicha tabla NAT no tiene absolutamente nada que ver con tu conexión a Internet que has delegado, no degrada absolutamente en nada al rendimiento de la línea, no es ningún cuello de botella, no hay ningún software/demonio interno que te esté de un modo u otro afectando a la línea/conexión. No existe ningún tipo de inestabilidad en el modo Monopuesto, ni problema de velocidad. Llevo usando el Modo monopuesto desde el primer HGU que salió, y lo tengo configurado ahora mismo en el HGU7 del mismo modo... cero problemas. Cero cuellos, cero inestabilidades, cero limitaciones, cero problemas de velocidad... Lo que quizás no termina de calar aquí, es que cuando usas el modo monopuesto, es tu Router el que pasa a gestionar TODA la conexión, internamente, el HGU actúa sobre la VLAN6 en esencia lo mismo en monopuesto que si fuese un bridge real, lo único que hace es quitarle/añadirle el etiquetado para que puedas usarlo... y no, esto no causa ningún problema ni cuello. Te podría poner montones de métricas tanto en Monopuesto como en modo Nominal, incluso como Bridge real (accediendo a la Shell interna y a mano), para que vieses el impacto que tiene: Cero.3. WIFI7 y MLO:
No es ninguna falacia de autoridad. Si me preguntas a mí personalmente, te diría que prefiero un Router que me de control total de cada parámetro posible, lo que son cientos de ellos, y parametrizarlo absolutamente todo, como hago con mis equipos. Eso no tiene absolutamente nada que ver cuando tienes que tomar en cuenta al usuario medio. Como puse en mi "review" (puedes leerla, está en el foro), soy el primero que critiqué a Movistar por no incluir la posibilidad de deshabilitar el SSID único aun a expensas de no poder usar MLO. Como dice en aquel post, aquí se ha primado por intentar maximizar el rendimiento WIFI "bruto" forzando las capacidades estrellas de WIFI7, como por ejemplo forzar el ancho a 160MHz, y no la estabilidad general. Es un problema únicamente de márketing, del mismo modo cuando los fabricantes hace ya años (aunque algunos aun lo hacen) configuran el Router en la banda de 2.4GHz para emitir en 40MHz. Eso no quiere decir ni mucho menos que creo que Movistar sí debería de permitir de forma más amigable la deshabilitación de esto, de hecho a nivel interno es trivial y la firmware está preparado para ello, únicamente hay que poner un botón/switch y listo. A pesar de ello, se puede usar de mientras el "parche" especificado.
4. Seguridad WPA y protocolos de legado
Como te dije en la primera ocasión, no tengo idea de que problemas hablas... La interfaz web ya permite todos los modos que consideramos normales a día de hoy: OWE, WPA2-PSK AES, WPA2/WP3 y WPA3-SAE. Hasta la fecha no he encontrado un solo dispositivo con problemas. Y ojo, me creo que pueda aparecer cualquier tipo de incompatibilidad con algún dispositivo en concreto, como es natural es imposible ver el comportamiento real del 100% de dispositivos del mercado. En los escenarios que he podido probarlo (en varios domicilios por cierto), no he visto ningún comportamiento anómalo en el modo Mixto
Sobre lo que dices de SSH en este punto, no tengo tampoco claro a que te refieres... sí, puedes hacerlo por SSH, pero... ¿con que objetivo? puedes configurarlo desde la interfaz Web sin ningún tipo de problema. De hechola interfaz SSH existente es, precisamente, para usuarios avanzados que pueden necesitar algún ajuste fino adicional que la interfaz Web no permite, es de suponer que esas necesidades las va a tener un usuario avanzado, y que por ende para él no es ningún problema el uso de SSH
5. Gestión de Canales y DFS
De hecho, una de las características mejores que tiene este HGU7, es que posee una antena dedicada únicamente para monitorizar el espectro de 5GHz, y así evitar el tiempo requerido y obligado para CAC. El algoritmo que provoca el salto, no tiene en cuenta únicamente el ruido que pueda existir en los bloques disponibles, sino que igualmente requiere por obligación, como es lógico, no saltar a ningún canal que esté en uso por radar/estaciones. El único bloque no DFS es el primer bloque, y es sólo de 80MHz. Si lo que quieres es evitar que salte, es la única forma de hacerlo, cualquier otro canal va a saltar, antes o después. La única diferencia es que gracias a la antena dedicada, el salto es cuasi-instantáneo. Obviamente es un salto, pero es que ese salto se va a dar, no se puede evitar, a menos que uses precisamente MLO o conexión simultánea. Antes de saltar, el Router por medio de 802.11h avisa a los dispositivos conectados del salto y el canal destino... pero aun así la "reconexión" es obligada, lo que en esencia se va a traducir en un micro-corte
Por cierto, como bien dices, los usuarios llamemos "avanzados" que requieren de unas altas prestaciones y fiabilidad, sobre todo si se dedican o hacen de forma extensa sesiones de streaming y gaming... no usan WIFI :), no es una decisión muy inteligente... ¿te imaginas servidores a los servidores de Google, Netflix, bancos.... que usasen Wi-Fi entre ellos? Y ya no por una cuestión únicamente de caudal, obviamente, en esencia es que la información es demasiado valiosa para dejarla en manos de una onda de radio que se muere, porque el vecino ha encendido el microondas. Simple como eso.
La única queja real que tengo en este punto con Movistar, y que ya expresé, es que como sucede con MLO y el SSID único, obligan a usar por defecto un ancho de 160MHz, y ahora mismo la interfaz web no permite establecerlo en 80Mhz, cosa que sí puede hacerse por SSH, y que espero que veamos en futuras actualizaciones.
6. Estabilidad de Firmware y Calor
Estás usando una falacia lógica. Sí, técnicamente el calor como es lógico degrada los componentes electrónicos de cualquier dispositivo, igual que podemos decir que cualquier movimiento mecánico va a causar igualmente un desgaste físico, por pequeño que sea. Y esto técnicamente es cierto. Ahora bien, en la práctica, y por lo general el tiempo de vida que usamos los equipos, va a ser que no. Esos Router que nombras de "alto rendimiento" propios que podemos encontrar en el mercado, sufren exactamente del mismo comportamiento. No tienen problema alguna en llegar a los 70ºC por tiempos prolongados, hasta el punto que algunas unidades pueden hasta quemar al tocarlas. Tengo por aquí un Ubiquiti que podría dar buena cuenta de ello. Esto no se puede evitar, a menos que quieras pagar el precio de una refrigeración activa, lo que implica ruido y punto de fallo. Coge cualquier Router del mercado con prestaciones similares, y mira la temperatura que alcanza.
Sí, el calor no perdona, es obvio, el thermal throttling está presente a día de hoy en prácticamente cualquier silicio, y ya nos enseñó el amigo Arrhenius lo que a la larga pasa. Pero como dije en su momento... ¿como lo hacemos? Porque no hay opción mágica. ¿Prefieres en tu caso particular meter refrigeración activa y que en 2-3 años el ventilador muerta y tengas que cambiarlo, además del ruído?? Oye, lo respeto, para gustos colores. ¿Prefieres en vez de eso optar por beneficiarte de la mayor tecnología de integración lo que ayuda a disipar mejor el calor pero sin aumentar los transistores? Perfecto también, sin ningún problema, tienes un hardware con componentes nuevos con un rendimiento de hace 3-4 años, pero que se calienta y consume mucho menos. Puede hacerse.. pero no es rentable para prácticamente ningún fabricante, a menos que sean dispositivos de nicho donde el consumo es esencial. No puedes meter un Switch con dos puertos 10GEthernet, una ONT Combo-PON, WIFI6/7... y pretender que con ventilación pasiva no se caliente.
Por cierto... culpar al calor generado por un Router de alto rendimiento por su efecto en el jitter... me parece una excusa un poco pobre teniendo en cuenta la de infinidad de factores y mucho más importantes y predominantes que afectan al Jitter. Sí, es totalmente posible que ante una carga descomunal, un flujo constante y severo durante un largos período, pueda hacer saltar el thermal throttling, y esto a su vez degradar de forma temporal el rendimiento del Router, lo que podría dar lugar también a aumentar la latencia o provocar un salto en el jitter, más aun si se está usando WIFI. Esto técnicamente es cierto... el problema es que en dicho escenario el Jitter por calor debería de ser lo último en preocuparnos, ya que el bufferbloat tendría un impacto mucho mayor por la carga en curso, ya sea directmaente por el bufferbloat, o indirectamente por las interrupciones que requiere realizar el Router. Y aun así en este caso, tenemos aceleración hardware con diferentes hilos de la NPU interna para lidiar con ello. ¿Esto hace que sea imposible sufrir este tipo de problemas? No, no es imposible sufrirlos, pueden llegar a pasar eventualmente... lo que pasa es que precisamente dado que requieren condiciones muy muy concretas para que se dispare un thermal throttling, cuando se dispara el efecto real que tendrá en el usuario será en esencia invisible. Yo al menos no conozco a nadie que esté descargando a una tasa de 10Gbit sostenida durante largo tiempo y al mismo tiempo jugando o haciendo uso de streaming por WIFI (donde se apreciaría aun más). Y repito, sí, puede llegar a pasar... con este Router y cualquiera de los que has mencionado... a menos que optes como digo por equipos profesionales, con disipación activa, flujos de aire dirigidos y otros.
7. Desdén técnico sobre el Filtrado MAC:Me da la sensación de que no has leído lo que puse. Copio y pego de nuevo, puesto que o no lo leíste, o simplemente fueron las prisas:
"Movistar prefirió, y en este caso lo aplaudo, a usarlo de un modo alternativo, a modo de un control parental simple. Ahí sí tiene cierto sentido su uso. Y para ello es necesario una interfaz más visual, que sea sencillo seleccionar un dispositivo para bloquearlo temporalmente, permitirlo etc etc. Y no soy fan de la App, ni tampoco creo que sea un buen modo de control parental teniendo otras opciones mucho mejores, pero entiendo que pueda tener cierta utilidad"Dicho de otro modo, ya expliqué que el filtrado MAC no tiene absolutamente ningún valor como seguridad, y es por ello por lo que Movistar prefirió usarlo a modo de "control parental". Según tus argumentos:
"Evitar la asociación automática de dispositivos conocidos pero no deseados en bandas específicas:"
Por un lado, al principio del todo alegabas la necesidad imperiosa (y la comparto) de poder separar las bandas... yo al menos lo prefiero, me da mayor control. No obstante, ahora parece que te contradices al decir que puedes evitar la asociación automática... ese problema no debería de existir por dos razones:
A) SI tienes bandas separadas, no se va a conectar a la otra, sin más.
B) Cualquier dispositivo decente, permite configurar la preferencia de banda
"Servir como inventario de activos autorizado (White List), algo esencial cuando se gestionan más de 30-40 nodos IoT."
Esto me parece aun más... "peligroso" si cabe. Es que directamente no vas a tener una red WIFI eficiente con 30-40 nodos IoT. Eso en esencia es un oxímoron. WIFI no se creó para eso, simplemente. Para eso tenemos tecnologías específicas para ello, como Zigbee por ejemplo, que ni siquiera es un protocolo IP, y aunque opera en la banda de 2.4GHz no se pisa ni interfiere el 99% de las veces, donde puedes convivir sin problema alguno 40, 50 y 100 dispositivos interconectados con un impacto de cero sobre tu red.Por otro lado, aun con todo, si quieres realizar un "inventariado" autorizado, me parece mucho más práctico y menos problemático una hoja de Excel donde apuntarlos. Eso sin contar el sobre-esfuerzo que requiere el SoC de un Router en estar recorriendo constantemente la lista interna... pero eso es otra cuestión totalmente diferente, en equipos modernos debería de ser menos perceptible, pero si lo que realmente te importa es el rendimiento de la red... no es el camino.
"Eliminar... bajo el pretexto de "seguridad falsa" es, en realidad, una claudicación del fabricante por no querer gestionar tablas de direcciones en memoria. Sustituirlo por una App móvil es trasladar el control del hardware local a la nube de Movistar, algo que vulnera la autonomía técnica del cliente. Otra cagada mas."
Me temo que no es así, y denotas de nuevo en este punto una falta total y absoluta de como funciona el HGU. Siento decirte que, para tu información, la información de dispositivos bloqueados/pausados, o como tu las llamas esas "tablas de direcciones en memoria", se guarda de forma íntegra en el Router, exactamente igual que en cualquier otro Router que puedas encontrar en el mercado. Movistar no guarda ni gestiona nada en su nube, esos datos no los guarda Movistar, si reseteas el Router, los ajustes relativos a ello se pierden. La App no es más que una interfaz visual simple para el usuario medio, que a su vez interacciona de forma indirecta con el Router, para bloquear, pausar, permitir... un dispositivo. Es el Router quien, a través de las listas blancas/negras de toda la vida se gestiona todo. Es más, por SSH se pueden ver, listar, añadir, eliminar... Así que siento decirte que no, no es otra cagada más, ni vulnera ningún tipo de autonomía técnica ni otras historias.
--------
Como final:
Los equipos de Movistar, como los de cualquier otro ISP van, como es lógico, orientado a la inmensa mayoría de usuarios, los que representan más del 95%. Precisamente para los que por el motivo que sea quieren usar su propio Router, pueden usarlo sin ningún tipo de problema, limitación, cuellos... Esa obligación Movistar la cumple y de sobras. Repito, desde que apareció el HGU5 hasta el HGU7 uso mis propios Router, jamás he tenido un solo problema, ni a 100M, ni a 10G. Pero es que aun así, ojo, aun con todo, Movistar tampoco te obliga a usar su HGU, al igual que eres libre de usar tu propio Router, eres igualmente libre de usar tu propia ONT. Del mismo modo que asumes los inconvenientes de usar tu propio Router, asumes los mismos inconvenientes de usar tu propia ONT.
Con todo ello, entenderás el motivo por el cual tus dos exigencias chocan de bruces con tu propio argumentariado. Dices que lo que quieres es, o poder usar un bridge real en el HGU para poder usar tu propio Router, o que te den una ONT para que puedas conectar tu propio Router. ¿No es eso un poco ilógico?
Movistar te permite sin problema alguno usar tus propios dispositivos, ya sea Router o ya sea ONT. Obviamente el usuario es el que tendrá que lidiar en cada caso con sus propios dispositivos. Es más, Movistar a diferencia de otros ISP no esconde parámetros exóticos ni raros, todas las configuraciones necesarias son globalmente conocidas, de modo que cualquiera con el hardware adecuado y conocimientos adecuados puede usar su propio Router, su propia ONT o ambos.
Aun así, Movistar facilita el uso del Router propio con el modo Monopuesto, mucho más coherente y sencillo de lidiar que con un bridge completo, y pese a lo dicho, no, no tiene limitaciones ni supone ningún cuello de botella... si quieres te puedo poner capturas y métricas usando mis propios equipos conectado el HGU7 en monopuesto. Cero problemas.
Si tenemos en cuenta que soy el primer crítico con Movistar en muchos aspectos, y que por descontado aun tienen que mejorar la firmware del HGU7 y aun así es como pienso y veo las cosas... francamente dudo enormemente que siquiera se puedan plantear ninguna de las dos opciones que te gustaría.
La primera, porque es el sistema que escogió hace mucho Movistar y es el que mejor resultado ha dado, porque implementar un bridge real limitaría enormemente a los usuarios, y porque para ese escenario lo más práctico es que el propio usuario usase su propia ONT.
Con respecto a la segunda, carece aun más de sentido, Movistar te entrega dispositivos adecuados para su uso en condiciones nominales que cubren a más del 95% de los usuarios, para ese 5% restante, Movistar no obliga a usarlos, si no te gusta el modo monopuesto del HGU por el motivo que sea, usa tu propia ONT y te apañas con ella, puede hacerse, Movistar no lo prohíbe, del mismo modo que usas (o quieres usar) tu propio Router.
----------
Como nota final:
Obviamente el HGU7 no es perfecto, nunca lo va a ser, ni este ni ningún otro Router que puedas encontrar en el mercado. El HGU es un equipo de un ISP, que tiene que bregar y ser bueno para todo en las condiciones del 95% de los usuarios. Yo soy el primero que uso mi propio Router!! No es por problemas de rendimiento, no es por problemas "mayores" de cuellos/jitter/ping/cortes.... ni nada de eso. Es por una cuestión de ecosistema propio (no me refiero a un ecosistema de un fabricante) de gestión y control, así como de funcionalidades que para mi son esenciales. Aun así, en mi configuración actual (que aquí si entiendo es un poco más... "especial" y no aplicable a nadie más), sigo usando el HGU7 en modo nominal aun estando en monopuesto, lo cual me permite aun más versatilidad para algunas cuestiones concretas. Podría usar una ONT propia?? Sin duda, tengo alguna por ahí y funciona sin problemas, simplemente es innecesario no podría asegurar nunca una robustez como la que necesito, y además el modo "dual" que tengo ahora me ofrece beneficios que para tenerlos tendría que añadir más hardware de red.
-Perfecto? No, ni mucho menos. Decente? Sin duda. tiene aun bugs que solucionar? Por supuesto, y más que saldrán.
-Movistar implementando un bridge real?? Lo dudo enorme enormemente. Suministrarte una ONT ellos mismos en vez del HGU? Lo dudo aun más.
-¿No estás conforme? ¿Tantos problemas te da? Usa el modo Monopuesto e instala el Router que te de la gana, no tiene limitación alguna ni problema conocido de nada. ¿Tampoco? usa tu propia ONT y Router, y así ya cualquier problema que puedas tener del tipo que sea no lo podrás achacar en modo alguno al hardware de Movistar (Realmente de Askey/Mitrastar). Yo desde luego es lo que haría, no te quepa la menor duda! Es lo que he hecho en el pasado y seguiré haciendo: si tengo una necesidad real que cubrir, nunca cojo atajos. lo estudio y lo soluciono de forma sencilla, práctica y sostenible.Saludos.
- alex-ltr25-03-2026Más integrado que la RDSI
Tienes toda la razón, porque hasta el momento no hay ningún usuario en España de Movistar 10Gbps que haya conseguido hacer funcionar con una ONT XGS-PON, si con un módulo SPF+ con ONT integrada.
Recordemos que todas las operadoras de España están obligadas por ley a permitir que los usuarios utilicen sus propios equipos si así lo desean.
Me parece increíble que las dos ONT supuestamente homologadas por Movistar simplemente no funcionen.
¿Qué opina la CNMC al respecto?
La normativa europea (Reglamento 2015/2120) y la Ley General de Telecomunicaciones española obligan a la libertad de equipo
- Theliel26-03-2026Yo probé el VDSL
Buenas alex-ltr
¿Y quien dice que no puedas?
Partamos de la base de que, que yo sepa al menos, no hay ninguna documentación pública que indique que ONT y firmware Movistar las tiene homologadas. Sí, todos conocemos el artículo de Banda Ancha, donde el autor mismo no cita fuente alguna, solo que tiene algo de información que puede dar, y que incluso podrían igualmente no funcionar. Con lo que, como bien dices, "supuestamente homologadas".
En cualquier caso, la homologación nunca ha sido un problema de nada. Es cierto que Movistar tendrán que homologar algunas probablemente por NEBA, y que con el paso de los meses aparecerán filtraciones de varios tipos con modelos concretos funcionando. Pero de nuevo, que una ONT esté o no homologada lo único que significa es que ha pasado los procesos de calidad interna, test... y fiabilidad por parte de Movistar. Esto no tiene absolutamente nada que ver con que no funcionen otras ONT,módulos SPF+ o incluso módulos SFP "stick" ONT. Una cosa es que, como es natural, tenga que homologar ciertos dispositivos para el mercado mayorista. Otra muy diferente es que únicamente funcione lo que está homologado. Esto lo vemos con todo constantemente... solo hay que ver las homologaciones para terminales 5G SA por ejemplo, cuando por lo general la inmensa mayoría de dispositivos 5G SA funcionan sin estar homologados.. la homologación es simplemente una "certeza".
En este caso, el problema es que no existe tal certeza, porque dicha información sobre las supuestas ONT homologadas es, en el mejor de los casos, difusa.
Por otro lado, y esto creo que lo discutimos en otro hilo o igual era este y honestamente he perdido el hilo (nunca mejor dicho), ya puse datos en los que, al menos en mi caso particular, no era necesario clonado de MAC ni otras historias. Nunca se ha tratado de si es posible o no es posible, sino de si se tiene el hardware y conocimientos adecuados, sin más. Y el problema de las ONT/SPF+ es el de siempre, y se divide en dos:
1º. No sabes a que OLT estás conectado... Por ahí se dijo, creo recordar, que Movistar usaría software virtual con módulos intercambiables... bien, eso será o seró, Movistar nunca ha puesto siempre todos los huevos en la misma cesta, y dudo que haga lo mismo. Con que dichos módulos sean intercambiables, ya tienes ajustes diferentes, gestión diferente problemas diferentes...
2º. Dependencia competa y total del propio fabricante que te vende el módulo/ONT/hardware. Cuando empezaron a aparecer los primeros módulos y ONT con GPON, muchos de ellos decían que si eran universales, que si funcionaban perfectamente, que sí... luego de llenarse la boca diciendo eso y negando la mayor que fuese su culpa, empezaron algunos a lanzar actualizaciones específicas que hacían que ahora funcionase al menos de forma parcial... pero incluso a día de hoy lo vemos en la red GPON, algunos que tienen sus propias soluciones funcionan bien, otros mal, otros regular. Aquí tenemos en esencia lo mismo, no hay grandes cambio en ello. Movistar no "capa" o restringe el hardware que cada uno quiera usar, otra cosa bien diferente es que tanto el fabricante del hardware usado como el usuario puedan hacerlo andar. A veces es únicamente limitación del hardware usado, a veces es únicamente limitación del usuario.
Dicho de otro modo... claro que tienes libertad total de usar tus propios dispositivos, aunque ya esto tiene muchos matices, dado que a día de hoy sigue el frente abierto si la ONT se considera o no parte de la infraestructura propia del ISP... pero bueno, dejemos eso a un lado... el caso es que sí, puedes usar tus propios equipos, pero tú te las apañas. Lo que no puede la CNMC es obligar a un fabricante de hardware es que de herramientas y soporte a un ISP concreto. La CNMC sí puede prohibir y prohíbe precisamente bloqueos a dedo, o no dar soluciones factibles y acordes. Y Movistar lo cumple, no solo a nivel de poder usar tu propio Router, sino también de usar tu propia ONT, que como digo toca un punto sensible de si es o no es punto final de su red.
Tengo algunas ONT/SPF+ por aquí (aunque no las uso en el día a día), al igual que uso mi propio Router, este último sí 24/7 (en monopuesto HGU7). Llevo unos 10/11 años con Movistar creo, y siempre ha sido así, con diferencias en el hardware que he usado, así como cuando Movistar usaba ONT independiente+Router. Mi red en esencia es la misma, pequeños ajustes cuando realizo cambio del equipo del ISP (Movistar en este caso) o de mis propios equipos. Y nunca he tenido un solo problema/limitación.
Sí, es totalmente cierto que no puedes usar cualquier hardware tengas los conocimientos que tengas, pero ya sea una ONT o ya sea un Router. Cuanto menos control completo y granular te de el fabricante, menos posibilidades tienes de hacerlo andar, puesto que empiezas ya a depender de lo que internamente ellos entiendan que es lo adecuado, que parámetros te permiten configurar, etc etc etc. Pero incluso dentro de los mismos fabricantes, esto cambia totalmente entre diferentes modelos. Ejemplo simple: He configurado perfectamente algunos modelos de Ubi , pero otros modelos de ellos simplemente no tenían en el kernel las librerías/modulos necesarios. Esto mismo podría decirlo de otros fabricantes. Por regla general, si el fabricante te permite acceso completo por Shell (ONT/Router), ya tienes el 70% para que funcione sin problemas. Otro 20% si permite de algún modo directa o indirectamente ejecución de automatizaciones al arrancar, y el otro 10% si el kernel mismo te lo permite o al menos el fabricante te proporciona el código fuente del kernel para poder compilar tus propios módulos (obligados por lo general por la GPL). De todo ello, incluso el primer cribado, ese 70% se puede sortear de muchas maneras, más ortodoxas o menos (generalmente sin el beneplácito del fabricante). Sobre el 20% es algo más complicado sortearlo si el fabricante no te lo permite, porque normalmente toca partes internas de la firmware... se puede sortear, pero es ya un nivel más profundo. Y el último 10% suele ser aun más complicado en caso de no tener soporte nativo a nivel de kernel/firmware y menos sin código fuente... únicamente te queda intentar buscar la rama más parecida y cruzad los dedos.
Así que, como entenderás, hay que matizar muy mucho que significa el poder usar tus propios dispositivos. Significa que el ISP no puede poner medidas tipo "bloqueos" de ningún tipo que eviten de forma manifiesta su uso. Eso es una cosa, y otra bien diferente es que el ISP pueda obligar a los fabricantes a que te den un hardware que sea plug&play.
Poder puedes sin ningún problema, pero tu te la apañas, yo lo llevo haciendo años y perfecto. Que no? Te esperas a que el fabricante X que sea lance un producto al mercado XGSPON ONT/SPF+ que certifiquen (ellos, el fabricante, no el ISP) que funciona con el ISP tal o cual... y si quieres y te fías lo pruebas, que si funciona perfecto y si no funciona pues te cagas en panete y en el fabricante por engañarte. Sin más.Saludos.
- alex-ltr26-03-2026Más integrado que la RDSI
Nunca se ha tratado de si es posible o no es posible, sino de si se tiene el hardware y conocimientos adecuados, sin más.
O sea que según tu en España somos todos tontos y no hay nadie que haya sido capaz de hacer funciona un ONT con la fibra Movistar 10Gbps en modo XGS-GPON. O que nadie tiene el hardware adecuado.
A mi eso me parece básicamente un impedimento.Por otro lado, y esto creo que lo discutimos en otro hilo o igual era este y honestamente he perdido el hilo (nunca mejor dicho), ya puse datos en los que, al menos en mi caso particular, no era necesario clonado de MAC ni otras historias.
Ten el enlace por si l has perdido:
ONT XSG-PON para fibra 10 Gb | Comunidad Movistar - 5321986
Partamos de la base de que, que yo sepa al menos, no hay ninguna documentación pública que indique que ONT y firmware Movistar las tiene homologadas. Sí, todos conocemos el artículo de Banda Ancha, donde el autor mismo no cita fuente alguna, solo que tiene algo de información que puede dar, y que incluso podrían igualmente no funcionar. Con lo que, como bien dices, "supuestamente homologadas".
Comisión Nacional de los Mercados y la Competencia
https://www.cnmc.es/sites/default/files/6368943.pdf
En Barcelona, a 15 de enero de 2026
De acuerdo con la información remitida por Telefónica, para provisionar todos los servicios mayoristas de NEBA Empresas basados en XGS-PON actualmente existen dos ONT XGS-PON monopuerto de nivel 2 homologadas:
1 - ZTE F2801SV3
2 - HUAWEI HN8010Ts-20