Så samlar du in Android VPN-loggar för ett supportärende

Du trycker på Connect, profilen snurrar en sekund och klienten rapporterar att anslutningen bröts. Supporten ber om loggar, du bifogar en skärmbild och tråden står still i två dagar eftersom ingen kan säga vilken del av handskakningen som gav upp. En rapport byggd kring ett enda försök, med ett smalt tidsfönster och det senast slutförda steget, flyttar ärendet framåt i en enda runda. Alternativet, en hel dags telefonloggar, ger oftast personen på andra sidan fler ställen att titta på.

Två telefoner på samma gateway kan ändå bete sig olika, eftersom protokollet, certifikatlagret, autentiseringsmetoden eller trafikpolicyn kanske inte stämmer överens. Det fungerar på min telefon är en utgångspunkt för jämförelse, inte bevis för ett Android-fel.

Fånga ett försök i stället för en hel dags historik

Skriv ner miljön innan du återskapar något: Android-version, tillverkare och modell, klientnamn och -version, profilen du valde, nätverket du är ansluten till och klocktiden med dess tidszon. Jag noterar också om batterisparläge eller Data Saver är på, eftersom båda ändrar vad klienten får göra när skärmen slocknar.

Avgör sedan vilket av fem utfall du faktiskt tittar på. Samtyckes- eller behörighetsdialogen slutförs aldrig, slutpunkten går inte att nå alls, autentiseringen avvisas, gränssnittsinställningen misslyckas efter en lyckad inloggning, eller så kommer tunneln upp och en specifik resurs förblir oåtkomlig. Var och en har en annan ägare och en annan åtgärd, och ett paket som blandar dem får svaret att försöka igen. Det är gissningarna mellan dem som gör ett ärende på en timme till en vecka av fram och tillbaka.

Övergångar spelar också roll. Om felet bara visas efter skärmlås eller efter ett byte från Wi-Fi till mobildata, skriv det i ärendets första rad och notera minuten då det hände.

Exportera först klientens egen logg

Den första bilagan bör komma från appen och inte från operativsystemet. De flesta klienter erbjuder export av diagnostik- eller anslutningslogg i inställningarna, ibland gömd bakom ett långt tryck på versionssträngen, och den exporten förstår redan sin egen tillståndsmaskin. Använd den som den kommer ut i stället för att skriva om de intressanta raderna i ärendets text.

Bifoga det första felet och händelserna direkt före det, inte bara den sista raden om bruten anslutning. En ren svans betyder oftast att det verkliga felet inträffade tidigare: en certifikatkedja som inte validerade, ett namn som löstes på ett oväntat ställe eller ett gränssnitt som aldrig konfigurerades.

Lägg bara till logcat för en fråga du kan namnge

En terminalemulator på telefonen är inte en systemloggare. Android loggar sina buffrar som separata cirkulära strömmar som bara privilegierade processer kan läsa i sin helhet. En vanlig app ser därför sin egen utdata plus en begränsad del, och påståendet att logcat var tomt bevisar väldigt lite om vad plattformen registrerade.

Den stödda vägen är en auktoriserad ADB-session från en dator du kontrollerar. Slå på utvecklaralternativ och USB-felsökning, anslut kabeln och acceptera RSA-fingeravtrycksdialogen på enheten; om den prompten stängs misslyckas varje senare kommando med unauthorized och ingen inspelning börjar.

Bekräfta att enheten verkligen är där innan du lägger tid på en inspelning. adb devices ska skriva ut serienumret följt av ordet device, och allt som visar offline eller unauthorized behöver först kabeln, prompten eller drivrutinen ordnad.

När den finns i listan börjar du spela in några sekunder innan du trycker på Connect och stoppar direkt efter att klienten ger upp. En live-inspelning med en medveten start slår en dump som tas tjugo minuter senare, eftersom ringbuffrarna redan har roterat och de tidiga raderna du behöver kan vara borta:

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

Filtrera på tid och tagg i stället för ordet VPN

Att söka igenom en inspelning efter vpn är det snabbaste sättet att tappa raden som förklarar felet. Certifikatvalidering, processkrascher och ändringar i anslutningen loggas under taggar som aldrig nämner VPN, så ett nyckelordsfilter behåller bruset och kastar beviset.

Begränsa först fönstret, sedan prioriteten, sedan taggen. När du bara behöver det som hände efter en känd tidpunkt spelar adb logcat -v threadtime -t '11-03 20:14:00.000' upp den senaste svansen från den punkten, och formatet threadtime håller tidsstämplar jämförbara med klientens egen export.

Om du känner till klientpaketet följer du dess process i stället för att gissa taggar. adb shell pidof com.vendor.client returnerar ett PID och adb logcat --pid=1234 -v threadtime skriver bara ut den processen, medan adb logcat -g visar hur mycket plats varje buffer har innan den börjar skriva över.

Dölj hemligheter och lämna sedan över ett sammanhängande paket

Innan något lämnar din maskin tar du bort lösenord, tokens, privata nycklar, sessionscookies och fullständiga enhetsidentifierare. Behåll felkoderna, ordningen på händelserna och adressrelationerna som gör felet läsbart, eftersom en inspelning som rensats förbi den punkten är lika oanvändbar som en som aldrig filtrerades.

Skicka sedan ett paket i stället för flera lösa filer: klientens export, ADB-fönstret namngivet med start- och stopptid, en tvåradig sammanfattning av steget som misslyckades och miljöanteckningen högst upp i den här listan. Om en del inte kan publiceras offentligt använder du leverantörens privata supportkanal och säger vilken fil som behöver den kanalen.

Kontrollera fyra saker innan du skickar. Täcker paketet ett försök och inte en hel eftermiddag? Överlappar klientens och systemets tidsstämplar? Och innehåller det fortfarande en token, ett lösenord eller en fullständig abonnentidentifierare? Rätta den sista punkten först och bifoga sedan filerna till det befintliga ärendet i stället för att öppna ett nytt, så att den som tar över behåller den tidigare kontexten.