Comment collecter les journaux VPN Android pour un ticket d'assistance

Vous appuyez sur Connect, le profil tourne une seconde et le client signale une déconnexion. Le support demande des journaux, vous joignez une capture d'écran et le fil stagne deux jours parce que personne ne peut dire quelle partie de la poignée de main a abandonné. Un rapport construit autour d'une seule tentative, avec une fenêtre temporelle étroite et la dernière étape terminée, fait avancer le ticket en un seul tour. L'alternative, une journée entière de journaux du téléphone, donne généralement à la personne en face plus d'endroits où regarder.

Deux téléphones sur la même passerelle peuvent encore se comporter différemment, car le protocole, le magasin de certificats, la méthode d'authentification ou la politique de trafic peuvent ne pas correspondre. Ça marche sur mon iPhone est un point de départ de comparaison, pas une preuve de panne Android.

Capturez une tentative plutôt qu'une journée d'historique

Notez l'environnement avant de reproduire quoi que ce soit : version d'Android, fabricant et modèle, nom et version du client, le profil choisi, le réseau auquel vous êtes connecté et l'heure de l'horloge avec son fuseau. Je note aussi si l'économie de batterie ou Data Saver est activée, car les deux changent ce que le client peut faire une fois l'écran éteint.

Décidez ensuite lequel des cinq résultats vous regardez vraiment. L'invite de consentement ou d'autorisation ne se termine jamais, le point de terminaison est totalement inaccessible, l'authentification est refusée, la configuration de l'interface échoue après une connexion réussie, ou le tunnel monte et une ressource précise reste inaccessible. Chacun a un propriétaire et un correctif différents, et un paquet qui les mélange reçoit une réponse demandant de réessayer. C'est deviner entre eux qui transforme un ticket d'une heure en une semaine d'allers-retours.

Les transitions comptent aussi. Si la panne n'apparaît qu'après le verrouillage de l'écran ou après un passage du Wi-Fi aux données mobiles, mettez-le dans la première ligne du ticket et notez la minute où c'est arrivé.

Exportez d'abord le journal du client lui-même

La première pièce jointe doit venir de l'application et non du système d'exploitation. La plupart des clients proposent dans les réglages un export de journal de diagnostic ou de connexion, parfois caché derrière un appui long sur la chaîne de version, et cet export comprend déjà sa propre machine à états. Utilisez-le tel quel au lieu de retaper les lignes intéressantes dans le corps du ticket.

Joignez la première erreur et les événements juste avant, pas seulement la dernière ligne de déconnexion. Une fin propre signifie généralement que la vraie panne a eu lieu plus tôt : une chaîne de certificats qui ne validait pas, un nom résolu à un endroit inattendu ou une interface jamais configurée.

N'ajoutez logcat que pour une question que vous pouvez nommer

Un émulateur de terminal sur le téléphone n'est pas un journal système. Android journalise ses tampons sous forme de flux circulaires distincts que seuls les processus privilégiés peuvent lire en entier. Une application ordinaire ne voit donc que sa propre sortie plus une tranche restreinte, et affirmer que logcat était vide ne prouve presque rien sur ce que la plateforme a enregistré.

La voie prise en charge est une session ADB autorisée depuis un ordinateur que vous contrôlez. Activez les options de développeur et le débogage USB, branchez le câble et acceptez la boîte de dialogue d'empreinte RSA sur l'appareil ; si cette invite est fermée, chaque commande suivante échoue avec unauthorized et aucune capture ne démarre.

Confirmez que l'appareil est bien là avant d'investir du temps dans une capture. adb devices doit afficher le numéro de série suivi du mot device, et tout ce qui affiche offline ou unauthorized a d'abord besoin que le câble, l'invite ou le pilote soient réglés.

Une fois qu'il est listé, commencez la capture quelques secondes avant d'appuyer sur Connect et arrêtez juste après que le client abandonne. Une capture en direct avec un début volontaire vaut mieux qu'un vidage pris vingt minutes plus tard, car les tampons circulaires ont déjà tourné et les premières lignes dont vous avez besoin peuvent avoir disparu :

adb logcat -v threadtime -b main,system,crash > attempt.txt

Filtrez par heure et étiquette plutôt que par le mot VPN

Chercher vpn dans une capture est le moyen le plus rapide de perdre la ligne qui explique la panne. La validation des certificats, les plantages de processus et les changements de connectivité sont journalisés sous des étiquettes qui ne mentionnent jamais VPN, donc un filtre par mot-clé garde le bruit et jette la preuve.

Réduisez d'abord la fenêtre, puis la priorité, puis l'étiquette. Quand vous n'avez besoin que de ce qui s'est passé après un instant connu, adb logcat -v threadtime -t '11-03 20:14:00.000' rejoue la fin récente à partir de ce point, et le format threadtime garde des horodatages comparables à l'export du client lui-même.

Si vous connaissez le paquet du client, suivez son processus au lieu de deviner les étiquettes. adb shell pidof com.vendor.client renvoie un PID et adb logcat --pid=1234 -v threadtime n'affiche que ce processus, tandis que adb logcat -g montre l'espace dont dispose chaque tampon avant de commencer à écraser.

Masquez les secrets, puis remettez un paquet cohérent

Avant que quoi que ce soit ne quitte votre machine, supprimez les mots de passe, jetons, clés privées, cookies de session et identifiants complets d'appareil. Conservez les codes d'erreur, l'ordre des événements et les relations d'adresses qui rendent la panne lisible, car une capture nettoyée au-delà de ce point est aussi inutile qu'une capture jamais filtrée.

Envoyez ensuite un seul paquet plutôt que plusieurs fichiers épars : l'export du client, la fenêtre ADB nommée avec son heure de début et de fin, un résumé de deux lignes de l'étape qui a échoué et la note d'environnement en haut de cette liste. Si une partie ne peut pas être publiée publiquement, utilisez le canal de support privé du fournisseur et précisez quel fichier a besoin de ce canal.

Avant d'envoyer, vérifiez quatre choses. Le paquet couvre-t-il une tentative et non tout un après-midi ? Les horodatages du client et du système se chevauchent-ils ? Et contient-il encore un jeton, un mot de passe ou un identifiant complet d'abonné ? Corrigez d'abord ce dernier point, puis joignez les fichiers au ticket existant au lieu d'en ouvrir un nouveau, pour que celui qui le reprend garde le contexte précédent.