ASKEY n53 (Changelog y algunas soluciones a sus problemas)

ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas tardes compañeros,

 

Los que ya me conocen por aquí saben que me encantan algunas cosas, entre otras, exprimir y toquetear en todos los sitios posibles. Y como he hecho en otras ocasiones, aquí va mi análisis preliminar de la "maldita" firmware n53 del ASKEY.

 

Tengo que decir que soy el primero que he sido muy reacio a instalarla, de echo lo he ido dejando hasta que he tenido un hueco más o menos prudencial, para revertir de forma rápida todo en caso de desastre. Y eso no es poca cosa, si tenemos en cuenta que hace ya meses que empezó a distribuirse de forma "aislada", aunque estas últimas semanas por lo que se ve pocos son los que no se les haya actualizado.

 

En pocas palabras como la definiría?? Incompleta, algún paso para adelante pero quizás 3 para atrás. Insistir en errores de políticas tomadas. Por desgracia, y es algo extremadamente habitual (lo raro es que no sea así), quien suele tener las "brillantes ideas" de cambiar algo y tienen el poder de decisión, no representan al 95% de los usuarios. Dichas decisiones nacen muchas de lo que a alguien se le ocurre de pronto, sin entender que lo que es bueno para uno puede no serlo para otro, no son usuarios de día a día, no hablan el mismo idioma. Y luego claro, el ego que es muy malo, el trabajo de rectificar... etc.

 

Bueno, veamos los cambios:

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

 

CHANGELOG n43 -> n53

(Kernel: 3.4.11-rt19+. Compilación: Mar 16 15:24:30 CST 2018)

 

 

Cambios Internos:

-Remodelación de la Shell limitada: Se suprime la salida de la mayoría de los comandos, pero siguen ahí y funcionando. Se quitan algunos, se añaden otros.

-Encriptación del cfg de configuración se mantiene igual, cifrado AES-256 y key: AskeyPU3SW2
-Limpieza profunda de archivos obsoletos o en deshuso.
-Eliminación de xupnpd, vpxy y otros, desarrollo que empezó Movistar para implementar en sus Routers emisores upnp para poder ver la TV en cualquier reproductor upnp
-Añadido librerías/binarios para hacer Roaming y Steering
-Añadido ipset y tproxy (McAfee Home Platform)
-Añadido soporte para McAfee Home Platform: Binarios y librerías... (Proxy de contenido, URLs...).. Se levanta en el puerto 8080, por donde es deducible que se controlará con una API interna. En primera conexión conecta a servidores de McAffe y descarga un buen contenido. Para los maníacos como yo, por lo general es suficiente cortar el acceso a servicediscovery.ccs.mcafee.com.
-Se levanta un nuevo "acceso" web, no tengo claro del todo aun la utilidad, no he tenido tiempo. Se levanta en el puerto 26661, requiere conexión segura usando Auth Digest, y la contraseña es "K1a5R9p4O3V"

-Sigue configurado por defecto Servidor remoto para recolección de logs:  wd.collector.logtrust.io
-Sigue Monitorización MAUI
-Mejora de forma sensible del tiempo de levantamiento de la Interfaz de 5GHz
-Actualización 1º y 2º fase Bootloader (u-boot y cferam)
-Actualización del Kernel y de la imagen del quantenna
-Actualización mayoría de binarios, librerías y módulos
-Se soluciona el problema con la enrutación de las DNS De CloudFlare (1.1.1.1)
-Se bloquea el acceso por defecto a la Interfaz Quantenna, aunque por otro lado se elimina el acceso por contraseña a su Shell.


Cambios Interfaz Web:

 

-Se elimina el control parental de la Interfaz Web Avanzada
-Se elimina la gestión de bloqueos MAC WIFI desde la interfaz Web Avanzada
    -Aun Accesible: http://192.168.1.1/wlmacflt.cmd?action=view
-Se elimina el menú de configuración para servidores SNTP de la Interfaz Avanzada
    -Aun Accesible: http://192.168.1.1/sntpcfg.html
-Se elimina el menú OMCI de la Interfaz Avanzada, aun accesible por URL
-Se restringe casi de forma completa la configuración WIFI avanzada de las dos interfaces
    -Se pueden rehabilitar anulando de forma simple el código en el navegador web.
-Se habilita por defecto WIFI Roaming y Band steering.

 (Band Steering lo hacen habilitando una interfaz 5GHz adicional (a modo de invitado) con el mismo nombre y ajustes que la interfaz de 2.4GHz, se puede deshabilitar)
-Se retocan diferentes otras páginas, algunas comprobaciones, saneamientos y otros.
-Diferentes Bugs en la representación de los datos de las páginas de instalación
-Cambios estéticos en la interfaz básica y otros ajustes.

-Sin control de sesión de loggeo, gran facilidad de colarse en el Router sin saber la contraseña.

Aplicación Móvil:
-Toda la comunicación se hace bajo HTTP, no HTTPS
-La contraseña de acceso al Router se transmite en texto plano
-Al ser la conexión en texto plano, tanto la contraseña del Router como de WIFI va de un lado a otro sin control alguno. Cualquiera en la red la puede saber.

-Problemas de conexión de la App con la n53 debido a, entre otras cosas, el servicio de McAffe provoca un leak de memoria que termina por hacer caer al propio servicio, y provoca a su vez que la app no conecte (o eso parece, esto último aun estoy investigando)

 

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

 

Problemas y Soluciones

 

Más o menos es a groso modo todo lo que se ha realizado. No todo es malo,lo que no entiendo es como algo que parece una versión beta/alpha se empieza a desplegar así, con fallos importantes, y capando además la posibilidad de deshabilitar las opciones más controvertidas o los cambios más profundos.

 

Se agradece el intento que están realizando por implementar WIFI Roaming o Band Steering, el problema es que al margen de que esté más o menos buggeado, no son funcionalidades que debería de estar habilitadas por defecto, hacer eso es una barbaridad, y encima no permitir deshabilitarlo es aun peor. Esto va a abrir la puerta a un sin fin de nuevos problemas WIFI para muchos. Sobre el papel WIFI Roaming o Band Steering es una buena idea, pero en la práctica depende del escenario de cada casa, de la compatibilidad con los dispositivos, de... optar de forma unilateral por habilitar WIFI Roaming sin dejar deshabilitarlo (por defecto) es una temeridad. Por supuesto, siempre desde mi punto de vista.

 

Para deshabilitar WIFI Roaming ver el siguiente párrafo. Para deshabilitar Band Steering es mas sencillo, si vamos a las redes WIFI de 5Ghz, veremos que aparecen 2, una la PLUS y otra con el mismo nombre que nuestra red de 2.4. Deshabilitando la red extra de 5GHz problema arreglado.

 

Del mismo modo es 5 pasos hacia atrás capar completamente la configuración WIFI, quiero pensar que alguien se equivocó y que la próxima versión más pulida revierta esto. Por suerte con pequeños ajustes en el navegador Web podemos volver a reabilitar cualquier ajuste que queramos cambiar, y se aplicará correctamente, incluyendo WIFI Roamming. Se trata simplemente de sacar las herramientas de desarrollo del navegador web, localizar el campo a editar, y eliminar la etiqueta "disabled" del código HTML.

 

Más preocupante me sigue pareciendo la recolección de datos que se hace a través de MAUI o incluso con el servidor de log remotos. Y para colmo de males, lejos de dar marcha atrás, se habilita por defecto también McAffee Home Platform, sin que en ningún momento se advierta al usuario. No obstante este último aun puede tener "salvación". La idea es buena, y si se implementa bien PERMITIENDO AL USUARIO SIEMPRE ESCOGER si desea usarlo o no, y por supuesto permitir a McAffe el acceso a nuestros datos. Por desgracia en todo esto poco podemos hacer. La única forma de deshabilitar la monitorización MAUI es hacer cambios internos en el Router, lo cual no es algo que haga casi nadie. Sobre McAffe tampoco se puede deshabilitar por ahora, pero quiero pensar que será posible. EL registro remoto de logs en cambio si se puede deshabilitar desde la interfaz avanzada. Dudo enormemente que Movistar esté cumpliendo con el RGPD en ninguno de los 3 supuestos citados... eso de "compartir/ceder" datos identificativos a terceros...

 

Otra de las cosas que me ha entristecido ha sido ver que han dado marcha atrás con la posibilidad de usar el Router como servidor upnp para la televisión. Una de esas funcionalidades que creo que iba a sentar muy bien a muchos, y me temo que no la veremos ver la luz.

 

Respecto a otros puntos de seguridad, me ha sorprendido que el acceso Web no realiza ninguna verificación por cookie. Por cierto, la contraseña se transfiere en texto plano, ya no voy a que sea bajo HTTPS, que tampoco, es que ni siquiera se hashea ni codifica en base64, nada de nada. El caso es que una vez el usuario se identifica, queda logeado por IP, no por sesión/contraseña, lo que significa que cualquiera en la red si quiere puede suplantar de forma sencilla el acceso, será que es complicado cambiar la IP privada dentro de una red...

 

 La idea de McAffe me parece buena como he dicho, explicaría la eliminación del control parental y el filtrado MAC, para implementarse todo en McAffee. Pero ojo, a ver como se hace. Veo que tendrá opción para proxear peticiones DNS y otros, que mientras sean opciones que el usuario pueda o no habilitar, genial. En lo personal siempre he estado en contra de todo esto, ya tenemos suficientes problemas de privacidad como encima estar enviando todas las páginas que visitamos y otras informaciones a terceros. No obstante no me parece mala idea, pensando siempre en la inmensa mayoría de usuarios, repito, siempre que nos dejen escoger. De todos modos esto también tiene los días contados, veo un "atraso" invertir tiempo en esto, cuando se está empezando a implementar incluso a nivel de navegadores Web el uso de DNS Over HTTPS, con lo que da igual el control parental que se quiera hacer, el Router no verá peticiones DNS. Firefox ya lo implementa de forma nativa, Chrome va de camino.

 

Sobre los cambios en la Shell reducida, me parece un sin sentido. Siguen manteniendo una shell (que el usuario normal puede acceder) totalmente capada, muy lejos a la que por suerte tiene el HGU Mitrastar. Pero esta vez aun peor, porque a pesar de que han añadido funciones muy útiles al usuario, han eliminado la salida por pantalla, con lo que a menos que el usuario sea adivino o un crack, de poco o nada le va a servir. Curioso de nuevo esto, invertir tiempo en sueldos para hacer la vida más complicada al usuario cortándole posibilidades interesantes (y bien intencionadas), cuando tienen fallos de seguridad de 1º grado que parece no importarles demasiado. Eso me lleva a pensar que, a título personal como siempre, al margen de políticas y decisiones las prioridades son muy cuestionables... ¿¿Una Shell reducida que vale para poco se hace aun más inservible para los pocos que les gustaría toquetear, y en cambio el acceso al Router por Web o, peor aun, por la aplicación que tanto se "vende" y que se quiere que use todo el mundo, transfiere contraseñas y otros en texto plano?? Si lo primero me parece cuanto menos incomprensible, lo segundo mejor no opino.

 

Lo peor de todo es que la Shell reducida permite de forma sencilla añadir filtros MACs (a pesar de que personalmente piense que es una tontería usar filtrados MACs). También permite cambiar las opciones WIFI que actualmente no permite la interfaz Web y otros.

 

La mayoría de problemas de la n53 son solucionables a día de hoy, excepto en todo caso el uso efectivo del control parental, que como digo a medio plazo el que quiera usarlo mejor que piense en otras alternativas, y no lo digo por la n53, sino porque no va a ser efectivo ni una cosa ni otra.

 

Que se impida por defecto editar las opciones WIFI me parece un sin sentido, así como habilitar de forma indiscriminada Roamming y Band Steering en WIFI, es querer tener más problemas WIFI de los que ya se tienen. A los que podemos controlar un poco más, sinceramente, nos afecta menos, ya sea por usar nuestros propios equipos o porque podemos a las malas reconfigurarlo a gusto, pero precisamente si miramos más al público en general, me parece un atraso. Siempre he dicho que una de las cosas que más me ha gustado siempre de Movistar ha sido su... "mano abierta" en ciertas cuestiones, y sinceramente llevamos un año que pienso que son palos de ciego y mal dados, restringiendo, complicando las cosas...

 

Y puedo estar equivocado y que no todos tengan mi visión, pero honestamente, cuando raro es el día que no piden unos cuantos compañeros un downgrade a la versión anterior... igual es que algo pasa y no se han hecho las cosas bien. No pasa nada por escuchar al cliente, que de aspectos técnicos a lo mejor no saben nada, ni de políticas, pero son los que mejor representan el día a día, la usabilidad, lo que realmente gusta, lo que no...

 

Saludos.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 1 de 46
5.425 Visitas
45 RESPUESTAS 45
Highlighted
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Hola @Theliel.

 

Muchas gracias por la información y por el excelente trabajo llevado a cabo.

Como te dije en otro hilo, esperaría tus informaciones antes de hacer otra cosa; ya lo he hecho: he solicitado downgrade del firmware.

 

Hay cosas que me repelen de esta última versión: la recolección de logs, la monitorización MAUI, puro espionaje, no se si estarían violando la RGPD, la plataforma McAfee sin otra alternativa, y aunque se pueda acceder a varias de las opciones de configuración utilizando ciertos atajos, saber esto solo servirá para que los corten en el futuro. Parece que la opción mejor es cambiar a modo bridge y utilizar otro router. 

 

La actitud de "mano abierta", como dices, fue una de las cosas que me hizo optar por esta compañía, pero ahora parece que está copiando todo lo malo de otras. No solamente es que no pasa nada por escuchar a los usuarios/clientes, usuarios porque usamos este router y clientes porque pagamos, si no que deberíamos tener o buscar un interlocutor a quien decirle lo que pensamos de estos cambios, porque a lo peor, no hay nadie escuchando ni valorando lo que está pasando.

 

Saludos

Mensaje 2 de 46
5.375 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @Cartulino

 

MAUI está presente igualmente ne la n43. Respecto al envío remoto de los Log no es la firmware en sí, sino la configuración, y también es así en la n43. Respecto a esas cuestiones, es igual en la n43. En la n53 es cierto que además entra en escena la suite de McAffee, que parece funcional (aunque con diversos bugs), pero para usar/gestionar de forma externa al Router, posiblemente a través de la app.

 

Los ajustes WIFI capados quiero pensar que es un "despistes", no tendría ningún sentido sinceramente que los dejasen así, y más aun forzando el uso de Roaming. Igualmente me parece mal como han implementado al menos en la interfaz Web el Band Steering, es un trabajo de "aficionados". Es cierto que BandSteering funciona como lo tienen implementado, pero para el usuario medio no tiene sentido ver en redes de invitados una red habilitada que se llama igual bla bla bla. Sería mucho mas simple que en las opciones avanzadas (deshabilitado por defecto) existiese un tick para habilitar Band Steering y ya está, sin que el usuario medio tenga que ver redes de invitados habilitadas e historias varias, que lo que da es confusión.

 

En términos generales, lo veo un atraso. Las novedades y cuestiones positivas, que sería la agregación de Roaming, Band Steering y McAffee se queda en nada por la mala política de Romaing y Band Steering (sin poder quitar el primero y siendo confuso el segundo) y la presumible necesidad de usar una app externa en el último caso. Y a cambio tenemos una firmware mas inestable, más capada (al menos de momento).


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 3 de 46
5.343 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

@Theliel,

Totalmente de acuerdo,

 

Creo que más que centrarse en añadir o capar funcionalidades deberian centrarse en corregir errores que llevan arrastrando de anteriores FWs, como es el del WPS, el cúal reporté a un tecnico de esta comunidad en la versión n41 y que se suponia iba a ser reparado en un futura actualización, el resultado actual es que van por la n53 y aún sigue ahí.

 

Al igual que activar por defecto Band Steering y Wifi Roaming, los cuales creo que están haciendo pedir a un gran número de clientes el downgrade por inestabilidades en la conexión WiFi.

 

Acerca de la implementación de McAffe, mis dudas tengo de que en algún momento llegue a ser algo seleccionable, más bien lo veria como una futura opción de pago como lo es el famoso Canguro Net Plus.

 

Lo de la recolección de datos MAUI no se hasta que que punto será legal pero creo que quizas ni el propio Movistar sepa muy bien que trato van a recibir dichos datos, al ser enviados a servidores de terceros directamente.

 

Un saludo

Mensaje 4 de 46
5.284 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @Kra1o5

 

Yo entiendo que mi "usabilidad", necesidades y modo de ver las cosas, no representa el grueso de los usuarios, pero es que jamás lo intento ver desde mi prima, que entiendo es diferente. Hay cosas que no tienen sentido...

 

Lo de WPS sigo sin entender bien que es lo que tenían en la cabeza para complicarlo de tal modo. Que si tienes WIFI habilitado lo puedes deshabilitar, pero si haces cualquier cambio a posteriori te dirá que si el SSID no está oculto, se habilita de nuevo. Vamos a ver, en seguridad una sencilla casilla que sea habilitar o deshabilitar, punto. Como funciona por cierto en el 99% de resto de equipos del mundo.

 

Band Steering/Roaming... lo digo de nuevo, es muy bueno ver que se implementan tecnologías nuevas, más opciones, bien!! Pero habilitar por defecto opciones que pueden dar problemas, y encima no dejar quitarlas por buenos modos, me parece sinceramente de pocas luces. Si ya hay muchas veces problemas de compatibilidad, explica a los usuarios normales que su movil se desconecta de forma "aleatoria", tarda X en volver a conectar o comportamientos erráticos. Que funcione para muchos no significa que funcione para todos. Hay que ser realistas y tener un mínimo de vistas. Si implementar X puedo asegurar más o menos más de un 95% de éxito puede incluso que me lo piense y me arriesgue a que un 5% tenga problemas, a expensas del otro 95%. Dejar "fuera" a un 5% me parece mucho, pero hablamos de % más elevados y sin poder diagnosticar de forma sencilla el problema. Es un error. Y eso sin entrar en el "problema" de tener ambos habilitados... porque claro, Steering ya en teoría puede desconectarte de una de las bandas de frecuencias para forzarte a la otra, imagínate la interacción con Roaming. Roaming por otro lado es menos lesivo por sí mismo, la inmensa mayoría no tiene otros AP...

 

Sobre McAffe también lo he pensado, que su gestión o uso esté superditado al alta de un servicio adicional y gestionado de forma paralela, posiblemente previo pago. Tendría bastante sentido si tenemos en cuenta que el Router levanta ahora 3 servidores HTTP, el habitual, otro McAffe y otro Movistar. Por desgracia aun no he tenido mucho tiempo de meterme con ello y ver que es lo que tienen pensado hacer en realidad y como se gestionaría.

 

Y sobre los datos bueno... conozco (creo) bastante bien el nuevo RGPD, pero no soy jurista, con lo que mi interpretación sobre ello podría ser totalmente equivocada. Pero mi opinión personal es que no lo cumplen en muchos puntos: Recolección de datos no anónimos, no consentimiento del usuario, no aviso ni declaración clara de su uso, no posibilidad de rescisión, no información de uso de terceros...

 

 


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 5 de 46
5.253 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)
Tiene un "fallo" con la desactivación de band steering. Al reiniciar el router se vuelve a activar la segunda red de 5GHz con el mismo nombre que la de 2.4GHz. También si cambiamos el nombre de esta segunda red, se cambia el de la de 2.4.
Mensaje 6 de 46
5.124 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @apocalypse

 

Sobre deshabilitarla y reiniciar, a mi al menos, me la ha mantenido deshabilitada, claro que por regla general ni siquiera uso WIFI en el HGU.

 

Respecto al cambio de nombre es totalmente normal y lo esperable, teniendo en cuenta que no se puede deshabilitar con un "check", para que sea posible hacer Band Steering ambas redes tienen que llamarse igual, con lo que modifica el nombre de la red principal para "obligar" que la red extra y la red principal se llamen igual.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 7 de 46
5.120 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)
Lo de que el nombre de la segunda red cambie de la de 2.4 lo entiendo. Era solo un comentario. Solo he probado reiniciarlo una vez desde que se me actualizó a la n53 y lo dejé todo configurado. Si me lo vuelve a hacer, lo resetearé de fábrica.
Mensaje 8 de 46
5.104 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Una pregunta. He encontrado la razón por la que los túneles 6to4 tienen serios problemas incluso en modo bridge:

 

https://comunidad.movistar.es/t5/Soporte-Fibra-y-ADSL/Funcionamiento-incorrecto-HGU-Movistar/m-p/359...

 

Resumiendo, la razón es que el HGU corrompe los paquetes PPPoE a su paso, sea hacia nosotros o hacia su concentrador. Sospecho que el concentrador ignora el campo Payload length del PPPoE.

 

¿sabes si esta versión podría solucionar ese problema? Yo estoy en n43 y me gustaría poder tener IPv6 decentemente. Cuando estoy en Londres la tengo en muchos sitios sin problemas, pero en España es mucho más complicado.

 

Saludos

Mensaje 9 de 46
5.045 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @nostromog

 

Leí tu hilo al que haces referencia, y no me queda claro algunas cosillas.

 

Dices que tienes el ASKEY en medio-bridge para poder hacer 6in4, con lo que presupongo que realmente el cliente PPPoE lo está ejecutando otro equipo de tu red, sea por ejemplo tu propio Router.

 

Sobre lo que has podido averiguar, aplaudo a las personas que, ante un problema que no logran ver de donde viene, se pelean un tanto con ello para sacarlo adelante.Se echa de menos que la gente se preocupe un poquito e intente buscarse las "habichuelas".

 

Sobre tu problema específicamente... no te podría asegurar. Yo llevo usando túneles 6in4 desde años, no por necesidad realmente, en mi caso es "experimentar"/"trastear", a día de hoy IPv6 es totalmente innecesario y aun pasarán muchos años hasta que lo sea. Actualmente tengo el Askey y como se puede deducir del propio hilo estoy con la n53. Detrás del ASKEY uso igualmente mi propio Router que realiza la conexión PPPoE y levanta también su propio tunel 6in4 (no siempre lo tengo levantado, llevaba un tiempo sin activarlo, a raíz de tu pregunta lo he levantado para ver que tal iba), y no tengo ningún problema, tampoco lo tuve en el pasado con la n43.

 

No puedo asegurarte con esto nada, es decir, puede que realmente el HGU esté alterando los paquetes PPPoE, no me ha dado por mirarlo la verdad, de echo en mi caso al menos el tunel se crea correctamente, y obviamente tengo conexión IPv6 completa en toda mi red interna.

 

Repito, creo que en la n43 tampoco he tenido ningún problema, pero no recuerdo cuando fue la última vez que lo probé en ella, si quieres, y tengo tiempo, le hago un downgrade y pruebo con al n43, tampoco me cuesta mucho.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 10 de 46
5.023 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Efectivamente, el PPPoE se hace en mi router. He hecho dos tipos de capturas de paquetes con pcap:
* "dentro" del HGU, haciendo mirror de un puerto del router en otro
* "fuera" del HGU, usando la opción "WAN Mirror" del Askey

En los dos casos observo comportamientos opuestos:
* dentro del HGU los paquetes hacia mi máquina tienen el payload del PPPoE incorrecto, por lo que mi máquina los tira y los que salen de mi máquina correcto. Además, los paquetes no tienen etiqueta VLAN, lógicamente porque los procesó el HGU.
* fuera del HGU los paquetes hacia internet tienen el payload del PPPoE incorrecto, y los que vienen de internet correcto. En ambos casos tienen la etiqueta 802.1Q VLAN (Pri:1, DEI: 0, id: 501)

Aparentemente el terminador de Telefónica está ignorando ese campo incorrecto, porque los paquetes de respuesta se ven "fuera" del HGU (correctos) y "dentro", en mi router (corruptos). Parece que mi router se niega a aceptar los PPPoE corruptos y por eso no funciona. Puede que la implementación de PPPoE que utilizas los acepte y por eso ese mal funcionamiento del HGU no te da problemas.

Me ha comentado gente que este problema existía (sin diagnosticarlo con precisión, me dijeron que el ACK no llega) y que variaba según hardware. No estoy seguro de si no todos los Askey corrompen los paquetes o de si no todas las implementaciones de PPPoE por ahí son igual de escrupulosas.

He lanzado en paralelo una petición a MikroTik, que es el router que tengo, a ver si permiten aceptar PPPoE con payload lenght incorrecta, pero aún no tengo respuesta.

También quería experimentar, cuando tenga tiempo. con alguna implementación de PPPoE en mi máquina, si hace falta puedo modificar el código de la implementación en modo usuario de Roaring Penguin. Porque ya he visto que la implementación del núcleo linux tira, sin más explicaciones los paquetes con longitud mayor que el skb, como es el caso. ( https://elixir.bootlin.com/linux/v4.14/source/drivers/net/ppp/pppoe.c )

Respecto a lo que dices de que "a día de hoy IPv6 es totalmente innecesario y aun pasarán muchos años hasta que lo sea", supongo que te refieres a España, y permíteme que discrepe. Aunque España sólo esté por envima de Bulgaria en uso de IPv6 de toda Europa, el sábado pasado el 24.86% de los accesos a Google a nivel mundial fueron a través de IPv6. Y si te dedicas a las telecomunicaciones como yo sabrás que hay que estar por delante del mercado, y no muy por detrás como nos está obligando Telefónica. Los "carrier grade NAT" tienen límites, aunque sea porque solo hay 65535 puertos a repartir. En UK y Alemania, donde paso mucho tiempo, es común estar accediendo a IPv6 sin saberlo, porque se entregan IPv6 en móviles o a usuarios domésticos. Las empresas van más lentas, pero parte de mi trabajo es anticiparme. Y Telefónica no me deja.

Mensaje 11 de 46
4.969 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @nostromog

 

Mi posición frente a IPv6 la he explicado otras veces. Que se tendría que a ver migrado a IPv6 de forma definitiva hace años? Si. Que como bien dices hay que intentar siempre estar un paso por delante?? Sin duda. Que CG-NAT es el demonio? Totalmente.

 

Ahora bien, al margen de todo ello, me reitero, a día de hoy IPv6 no es necesario, desde mi concepción de como son las cosas, sencillamente me hago dos preguntas básicas: ¿Puedo prescindir de IPv4? No, imposible. ¿IPv6 permite acceder a algún servicio que no sea posible por medio de IPv4? Tampoco. Eso no significa que no me gustaría disponer de IPv6 nativo, como te he dicho uso 6in4, pero soy realista. Mejoras de seguridad por un lado peores por otras, mejoras de rendimiento por otro peores por otro... al margen de las diferencias de protocolos, IPv6 nació para solucionar el direccionamiento IPv4, y como por ahora por desgracia lo han ido sorteando, pues no se ha avanzado demasiado.

 

https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/

 

Un 25% de dispositivos conectados en teoría soportarían IPv6, siendo tan solo un 5% el tráfico realmente por IPv6. Esos datos están muy muy muy lejos de ser los deseables, con esos datos y el ritmo actual, IPv6 (de forma masiva claro está) se demorará 10-20 años, y posiblemente otros 10-20 años en "desaparecer" IPv4. Como por desgracia no es algo que "venda", el interés que ponen los ISP,centros de datos, redes, fabricantes de hardware.... es mínimo.

 

-----------

 

Volviendo a lo que estábamos hablando

 

Respecto a como envía o no el Askey los paquetes hacia fuera no te puedo decir porque como te digo no me he puesto a analizarlo, pero si tengo tiempo estos días hago capturas internas  a ambos lados y veo como salen y entran en este aspecto los paquetes.

 

Si te digo que no es la primera ni la segunda vez que veo a otros compañeros con problemas de compatibilidad con MikroTik y el cliente PPPoE. Cuidado que no estoy diciendo que sea un problema siquiera de MikroTik, podría ser problemas sencillamente de interoperatividad entre el cliente PPPoE de MikroTik y el Juniper o el concentrador que esté al otro lado. Que ahora mismo me vengan a la memoria, recuerdo casos, por ejemplo, donde el  MikroTik ignoraba totalmente el MTU de la conexión PPPoE establecido, cuando recibía la respuesta desde el servidor PPPoE de Movistar con MTU 1492, este "reseteaba" el MTU interno a 1460.

 

Como te digo, no he tenido problemas nunca con el ASKEY en establecer túneles 6in4 ni con ASUS ni con cliente "propio" en Debian. Pero de nuevo esto no es garantía de nada, los problemas de compatibilidad existen desde siempre, y puede ser realmente que el problema esté que Mikrotik suelta los paquetes sin tener que hacerlo y sea muy quisquilloso, o cualquier otra cosilla.

 

Como te digo aunque solo sea por curiosidad voy a echar un ojo a ver...

 

Respecto al ASKEY específicamente y que pudiese ser una revisión específica la que falla... no creo, como te digo apunto mucho más a un fallo de compatibilidad entre cliente/servidor PPPoE. Luego como te digo si tengo un ratito hago capturas y hecho un ojo


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 12 de 46
4.960 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

@Theliel  ha escrito:

Buenas @nostromog

 

Mi posición frente a IPv6 la he explicado otras veces. Que se tendría que a ver migrado a IPv6 de forma definitiva hace años? Si. Que como bien dices hay que intentar siempre estar un paso por delante?? Sin duda. Que CG-NAT es el demonio? Totalmente.

 

Ahora bien, al margen de todo ello, me reitero, a día de hoy IPv6 no es necesario, desde mi concepción de como son las cosas, sencillamente me hago dos preguntas básicas: ¿Puedo prescindir de IPv4? No, imposible. ¿IPv6 permite acceder a algún servicio que no sea posible por medio de IPv4? Tampoco. Eso no significa que no me gustaría disponer de IPv6 nativo, como te he dicho uso 6in4, pero soy realista. Mejoras de seguridad por un lado peores por otras, mejoras de rendimiento por otro peores por otro... al margen de las diferencias de protocolos, IPv6 nació para solucionar el direccionamiento IPv4, y como por ahora por desgracia lo han ido sorteando, pues no se ha avanzado demasiado.

 

https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/

 

Un 25% de dispositivos conectados en teoría soportarían IPv6, siendo tan solo un 5% el tráfico realmente por IPv6. Esos datos están muy muy muy lejos de ser los deseables, con esos datos y el ritmo actual, IPv6 (de forma masiva claro está) se demorará 10-20 años, y posiblemente otros 10-20 años en "desaparecer" IPv4. Como por desgracia no es algo que "venda", el interés que ponen los ISP,centros de datos, redes, fabricantes de hardware.... es mínimo.

No sé si has leído el informe que me pones, porque yo saco conclusioes opuestas. Me encanta especialmente la Figura 5: "G20 Countries with less than 5% IPv6 deployment", que seguramente "liderará" Rusia seguida muy de cerca por España, porque Turquía, Italia y Sudáfrica nos superan.

 

-----------

 

Volviendo a lo que estábamos hablando

 

Respecto a como envía o no el Askey los paquetes hacia fuera no te puedo decir porque como te digo no me he puesto a analizarlo, pero si tengo tiempo estos días hago capturas internas  a ambos lados y veo como salen y entran en este aspecto los paquetes.

 

Si te digo que no es la primera ni la segunda vez que veo a otros compañeros con problemas de compatibilidad con MikroTik y el cliente PPPoE. Cuidado que no estoy diciendo que sea un problema siquiera de MikroTik, podría ser problemas sencillamente de interoperatividad entre el cliente PPPoE de MikroTik y el Juniper o el concentrador que esté al otro lado. Que ahora mismo me vengan a la memoria, recuerdo casos, por ejemplo, donde el  MikroTik ignoraba totalmente el MTU de la conexión PPPoE establecido, cuando recibía la respuesta desde el servidor PPPoE de Movistar con MTU 1492, este "reseteaba" el MTU interno a 1460.

Esos problemas antiguo que dices me despistaron mucho. Ahora mismo no existen, pero no lo he podido verificar hasta que he entrado al wireshark y los mirrors de WAN en los dos lados de la conexión. Definitivamente puedo demostrar que el problema es de funcionamiento del HGU, y si hubiera alguna forma legal de prescindir de él me ahorraría su consumo (es brutal lo que se calienta) y el espacio que ocupa ese pisapapeles gigatesco, porque uso mi propio cliente SIP, no tengo TV y está en modo puente... y encima no funciona.

 

Como te digo, no he tenido problemas nunca con el ASKEY en establecer túneles 6in4 ni con ASUS ni con cliente "propio" en Debian. Pero de nuevo esto no es garantía de nada, los problemas de compatibilidad existen desde siempre, y puede ser realmente que el problema esté que Mikrotik suelta los paquetes sin tener que hacerlo y sea muy quisquilloso, o cualquier otra cosilla.

 

Como te digo aunque solo sea por curiosidad voy a echar un ojo a ver...

 

Respecto al ASKEY específicamente y que pudiese ser una revisión específica la que falla... no creo, como te digo apunto mucho más a un fallo de compatibilidad entre cliente/servidor PPPoE. Luego como te digo si tengo un ratito hago capturas y hecho un ojo

 

Dos temas:
* Las personas que me reportaron el problema me dijeron que era aleatorio, que fallaba en unos sitios y en otros no. Eso podría depender de revisiones de hardware o similar...

* He probado hace un rato con pppoe desde mi ordenador y se comporta 100% igual: ipv4 funciona, el túnel ipv6 levanta, pero las conexones TCP fallan porque mi pc no recibe el paquete siguiente, igual que el router.

 

Como te dije no sé si existen otras implemetaciones de pppoe que ignoren o corrijan ese tema, pero la del kernel de linux no es una de ellas. A ver cuando saco tiempo para probar rp-pppoe, un poco má laboriosa de configurar...


Mensaje 13 de 46
4.935 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @nostromog

 

Que España esté a la cola no te lo discuto compañero, para algunas cosas nos gusta en este país llenarnos la boca, para otras damos vergüenza... muchas veces escuchamos eso de que somos un "país de pandereta", y la mayoría se suele quejar de políticos como causa, cuando el problema es la mentalidad, formas, carácter... del  español. Los ISP aquí se comportan simplemente como la sociedad  nuestra les marca, reguladores/políticos que también escogemos, y el Chiquilicuatre fue a Eurovisión porque lo votó las personas y...

 

-------

 

Puedes prescindir del HGU sin problema alguno. Tienes varias opciones que, llegado este caso podrías hacer:

 

1. Solicita que te instalen una ONT independiente y colocas detrás el Router que quieras, normalmente, y en ciertas ocasiones, lo hacen sin muchas pegas

 

2. Usa tu propia ONT, hay varias alternativas que puedes usar, aunque en este caso específico tendrás que lidiar tú solo con las posibles complicaciones que puedan aparecer, y dependen mucho del equipo que tengan ellos al otro lado en tu zona. He configurado ONT propias que han funcionado (funcionan) perfectamente, y otras que han sido imposible por cuestiones de interoperatividad con las OLT

 

3. Solicitar un cambio de HGU por otro, ya sea otro ASKEY u otro Mitrastar, en caso de que fuese un problema en la revisión del hardware, se podría solventar.

 

Sobre problemas de MTU han sucedido, ya te digo que en lo personal no te puedo asegurar nada ni menos verificar debido a que no tengo ningún Mikrotik, todo ello sólo puedo transmitirte lo que otros compañeros a lo largo de los años se han "quejado" por aquí, con capturas y otros. Solucionado o no, que fuesen problemas de configuración... ya eso no te lo puedo decir.

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

 

Respecto específicamente con el ASKEY, lo siento soy muy curioso, me he puesto a realizar capturas en todas las partes para ver si existía alguna anomalía, todo ello siempre con tcpdump

 

1º. Captura en el bridge de mi Router (br0) -> Todo normal, el tráfico de algunos equipos tageados con VLAN ID 1 por un Switch

 

2º. Captura en Interfaz PPPoE de mi Router (ppp0) -> Todo correcto, aparece ya las cabeceras PPPoE, tanto paquetes de entrada/salida los campos de longitud son los adecuados.

 

3º. Captura en el medio-bridge del ASKEY (br0) -> Todo correcto, cabeceras PPPoE, correctas, longitudes correctas... y lo mismo para el tráfico 6in4.

 

4º. Captura en interfaz gpon del ASKEY (gpon0) -> Todo correcto de nuevo.

 

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

 

Nunca me he fijado en ello en versiones anteriores, con lo que honestamente como te dije no te puedo decir que sea un bug ya corregido en la n53 o que haya sido alguna revisión de hardware o... si tengo tiempo le pongo la n43 y hecho otro ojo, a ver si los datos son iguales o veo discrepancias.

 

Que sea un error de revisión de hardware me parecería bastante raro la verdad, pero cosas peores se han visto. Que recuerde, hasta hace unos 2-3 meses al menos, han sido unas 2-3 revisiones de hardware, sobre posibles cambios no tengo información al respecto, me temo.

 

Puedes intentar forzar la actualización y probar, pero... siempre puede solicitar que te pongan la n43 teniendo en cuenta los problemas que ha dado


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 14 de 46
4.923 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

@Theliel  ha escrito:

Buenas @nostromog

 

Mi posición frente a IPv6 la he explicado otras veces. Que se tendría que a ver migrado a IPv6 de forma definitiva hace años? Si. Que como bien dices hay que intentar siempre estar un paso por delante?? Sin duda. Que CG-NAT es el demonio? Totalmente.

 


En el tema de IPv6 Movistar lleva casi una década cada x tiempo anunciando grandes pruebas piloto, pero al final después de tantos años se les ha adelantado Orange/Jazztel. Al paso que vamos Movistar lo habilitara cuando no le quede más narices y de mala manera. Y que surgen problemas con la migración, pues sí, pero eso no significa quedarse anclado y tener que moverse cuando ya no queda otro remedio..

Mensaje 15 de 46
4.902 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)
Puedes intentar forzar la actualización y probar, pero... siempre puede solicitar que te pongan la n43 teniendo en cuenta los problemas que ha dado

¿cómo se fuerza una actualización? No sé si una entrada en este foro cuenta como "abrir una incidencia" pero me han pedido datos personales asociados al contrato desde Soporte Técnico, así que considero que la abrirán.

 

Si me actualizan y no funciona considero que deberían cambiarme el HGU por uno que no tenga ese comportamiento o un ONT+router de forma que pueda guardar el router en el trastero y funcionar con ONT+mi router.

 

Por cierto, En este hilo está el resultado de mi última prueba: parcheé rp-pppoe y lancé el túnel PPPoE y el de 6to4 en mi portátil. y todo funciona perfectamente, además de mostrar errores en el log los paquetes ilegales que fabrica el HGU.

Mensaje 16 de 46
4.870 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas compis,

 

@ljfg cierto, pero es verdad que cada vez estamos más cerca, de echo hace ya tiempo que la mayoría de centralitas de Movistar de Fibra asignan IPv6, aunque aun no están prefijandolas y no son funcionales, pero ha habido movimientos, no todo está perdido... esperemos que no tengan que esperar otros 5 años

 

@nostromog reseteándolo. Resetea y espera que haga la carga primero de tu configuración y luego de la firmware. Si al rato no lo ha hecho, resetea de nuevo. A menos que hayan parado su distribución, que todo es posible, debería de entrarte


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 17 de 46
4.853 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

@Theliel  ha escrito:

Buenas compis,

(...)

@nostromogreseteándolo. Resetea y espera que haga la carga primero de tu configuración y luego de la firmware. Si al rato no lo ha hecho, resetea de nuevo. A menos que hayan parado su distribución, que todo es posible, debería de entrarte


Entiendo que te refieres a la opción "Restaurar valores de fábrica", porque reinicios he hecho unos cuantos con estas movidas y ponerlo en modo bridge y sigue con el otro

Mensaje 18 de 46
4.837 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

🙂

 

* Hice copia de seguridad de la configuración

* Restaurar a valores de fábrica

* Se espera un buen rato

* Vuelve con el n53

* Miro que más o menos es igual un poco menos cutre, pero... a lo que importa

* Restauro mi configuración, reinicia

* Vuelve y OMG! está la wifi activada, algo fue mal (pensé yo incorrectamente)

* Restauro otra vez y reinicia de nuevo. Esta vez soy un poco más paciente y me doy cuenta de que desde que reinicia tarda mucho en restaurar... me espero y ya está otra vez en modo puente.

* Entra mi router, etc. Levanto el túnel y....

FUNCIONA!!!

 

Ahora mi internet va más fluida, al estar las conexiones típicas de CDN a IPv6: youtube, facebook, etc... sin NAT.

 

Gracias por tu ayuda, y voy a decirles a gente que tenía el mismo problema que si tienen el Askey n43 -> n53 lo arregla.

Mensaje 19 de 46
4.825 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @nostromog

 

Gran noticia, al menos que hayan solucionado algún problema que otro y no solo meter la pata como la han mentido. Por suerte, para los que lo tengan en medio-bridge la mayoría de los problemas no debería de serles demasiados problemáticos.

 

🙂


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 20 de 46
4.816 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

@Theliel

Podrías explicar cómo hacer esto?

Gracias.


 

@Theliel  ha escrito:

 Cambios Internos:

-Se restringe casi de forma completa la configuración WIFI avanzada de las dos interfaces
    -Se pueden rehabilitar anulando de forma simple el código en el navegador web.

 

Mensaje 21 de 46
4.788 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @xixon1979

 

Está explicado en el post:

 

"Del mismo modo es 5 pasos hacia atrás capar completamente la configuración WIFI, quiero pensar que alguien se equivocó y que la próxima versión más pulida revierta esto. Por suerte con pequeños ajustes en el navegador Web podemos volver a reabilitar cualquier ajuste que queramos cambiar, y se aplicará correctamente, incluyendo WIFI Roamming. Se trata simplemente de sacar las herramientas de desarrollo del navegador web, localizar el campo a editar, y eliminar la etiqueta "disabled" del código HTML."

 

 


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 22 de 46
4.771 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

@Theliel  ha escrito:

Buenas @xixon1979

 

Está explicado en el post:

 

"Del mismo modo es 5 pasos hacia atrás capar completamente la configuración WIFI, quiero pensar que alguien se equivocó y que la próxima versión más pulida revierta esto. Por suerte con pequeños ajustes en el navegador Web podemos volver a reabilitar cualquier ajuste que queramos cambiar, y se aplicará correctamente, incluyendo WIFI Roamming. Se trata simplemente de sacar las herramientas de desarrollo del navegador web, localizar el campo a editar, y eliminar la etiqueta "disabled" del código HTML."

 

 


Gracias, me debí saltar el párrafo sin darme cuenta.

Mensaje 23 de 46
4.768 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

@Theliel

Muchas gracias por el maravilloso desglose... una pregunta sobre la parte de Roaming... ¿Es compatible con OpenWrt?
Lo comento pues me gustaría probarlo, pero las opciones que aparecen en openwrt y en el router de movistar, no se parecen!

Gracias,

Mensaje 24 de 46
4.640 Visitas
Re: ASKEY n53 (Changelog y algunas soluciones a sus problemas)

Buenas @Theliel,

 

Tras una conversación a través del Chat técnico de Movistar me han confirmado que desde el día 20 de Septiembre la versión n53 es la más reciente para el HGU Askey.

Existía una n54 en fase beta pero la han retirado por ahora y no se puede instalar aún solicitándolo así que parece que la n53 ha venido para quedarse bastante tiempo.

 

Un saludo,

Mensaje 25 de 46
4.297 Visitas