Incidencia con el proxy DNS en el router HGU - Mensajes msg_len -1 en log
Hola, abro este hilo para solicitar asistencia tecnica o una actualizacion de firmware para mi router HGU. He revisado el registro (syslog) de mi equipo porque algunos dispositivos (como la videoconsola y altavoces inteligentes) experimentan microcortes o lentitud al arrancar.
En el log aparecen errores constantes del proceso "dnsproxy" que indican un fallo al procesar la longitud de los mensajes (error msg_len = -1), obligando a los equipos a renegociar la conexion continuamente.
Detalles del registro del router (adaptado para el foro):
ERROR: dnsproxy dproxy . c : 760, nlseq=10927, NLMSG_OK == 0
ERROR: dnsproxy dproxy . c : 996, ip = 192 (punto) 168 (punto) 1 (punto) 48, msg_len = -1
EVENTO POSTERIOR: CWMP Receive RTM_CFG_NAT_PORT_MAPPING_CHANGED event
El fallo ocurre tanto con direccionamiento IPv4 local como al intentar gestionar peticiones mixtas IPv6.
Agradeceria si un tecnico de segundo nivel pudiera revisar la linea y comprobar si mi router HGU cuenta con la ultima version de firmware estable disponible para corregir este bug del dnsproxy, o si es necesario un cambio de equipo.
Gracias y saludos
Buenas PISTOTEL
Aunque parezca una tontería, hay mucho que entender y ver en tu cuestión, aunque en principio no tendría que ver absolutamente nada con tener microcortes o lentitud al arrancar por varios motivos, pero vamos a ir desglosando todo:
1º. Por defecto no se usa DNSProxy
A día de hoy, la gestión DNS que hace Movistar con sus dispositivos es de asignación directa por DHCP. No manda como servidor DNS al propio HGU, sino que asigna directamente las IPs de sus servidores DNS (80.58.61.250/254). Es decir, que es el cliente el que envía la resolución DNS directamente al servidor de Movistar, o cualquier otro que uno quiera configurar en el DHCP del Router. Esto hace que cualquier demonio interno habilitado para DNS, en este escenario, no haría absolutamente nada.
Sí existe un escenario en que esto se "rompe". Movistar tiene el servicio de "Conexión Segura". Aquí la cosa si cambia, porque parte de como funciona ese "Conexión Segura" es interceptando el tráfico DNS. Aquí es donde sí se usa dnsproxy de forma real en el HGU. Cuando se habilita, los servidores de Movistar digamos "levantan" ciertos servicios en el HGU, como reputación de sitios y otros. Dado que el HGU asigna por DHCP las DNS, ahora sí entra en juego e intercepta internamente las peticiones DNS, para permitirlas o no dependiendo de bases de datos de reputación y otros.
Es decir... que si no tienes el servicio de Conexión Segura habilitado y te salen dichos mensajes, es ruído raro que registra. Si tienes el servicio habilitado, solo entonces en principio el servicio si está corriendo
2º. Pongamos que usas Conexión Segura
En este escenario, podría pasar perfectamente que un paquete DNS mal formado o que no le gustase demasiado al proxydns interno fallase. Esto no es nada raro, ya sea una longitud incorrecta o cualquier otra cosilla. Ejemplo simple de esto, toda mi red pasa por un servidor propio PiHole, que a lo largo del día registra decenas de errores DNS, ya sea por invalidación DNSSec, tamaño [....], registros mal formados... de todo. Generalmente de dispositivos concretos.
No obstante, un error puntual en esto, que puede pasar, no afectaría ni se vería como problemas al arrancar o microcortes. Tu red está enviando constantemente peticiones DNS. Por poner datos claros... mi red no es muy grande, en total serán 10-15 dispositivos más o menos. En las últimas 24h se han registrado (sin contar cuando los terminales han estado con datos o usando DoT/DoH) más de 100.000 resoluciones. Eso es a más de una petición DNS por segundo.
Cuando por cualquier motivo un dispositivo falla en una resolución, manda otra directamente. Es más, por lo general no mandan siquiera una sola, depende del OS puede mandar 2 en paralelo a cada servidor DNS configurado. Aun cuando fallasen ambas, pasan muy muy poco tiempo en otra resolución. No notarías microcortes, y mucho menos un tiempo de espera alto en iniciar.
Lo que sí podría pasar es que el fallo provocase un Crash en el servicio DNSProxy, que este tardase en volver a iniciarse, y eso si podría provocarte problemas. Pero sabemos que eso no te pasa, o el problema lo tendrías en todos los dispositivos, no solo en alguno en particular. El proceso no está crasheando, simplemente un error en la resolución DNS de esa petición, posiblemente por mal formado.
Ese error no obliga a renegociar ninguna conexión ni mucho menos, en cuanto la DNS se resuelve, la conexión se establece a nivel IP, y sigue funcionando sin ninguna otra interacción DNS. Únicamente cuando se inicia otra conexión nueva, antes de ella, se lanza la petición DNS, y una vez se resuelve la conexión se establece. Como te digo son muy habituales los errores de longitud DNS... si es que es el caso, pero es habitual, que no quiere decir ni mucho menos que el servicio DNSProxy sea sólido como una piedra, ojo, no estoy diciendo eso, tendrá sus fallos, estoy totalmente seguro de ello.
A pesar de que tengo dicho Router, no puedo depurarte aun más el problema dado que no tengo Conexión segura habilitada, y el servicio por ende no se levanta,
Saludos.
