Slik samler du inn Android VPN-logger for en støtteticket

Du trykker på Connect, profilen spinner et sekund, og klienten rapporterer at forbindelsen er brutt. Støtte ber om logger, du legger ved et skjermbilde, og tråden står i to dager fordi ingen kan si hvilken del av håndtrykket som ga opp. En rapport bygget rundt ett forsøk, med et smalt tidsvindu og det siste fullførte trinnet, flytter saken videre i én runde. Alternativet, en hel dag med telefonlogger, gir vanligvis personen på den andre siden flere steder å se.

To telefoner på samme gateway kan fortsatt oppføre seg forskjellig, fordi protokollen, sertifikatlageret, autentiseringsmetoden eller trafikkpolicyen kanskje ikke stemmer overens. Det fungerer på telefonen min er et utgangspunkt for sammenligning, ikke bevis for en Android-feil.

Fang ett forsøk i stedet for en hel dags historikk

Skriv ned miljøet før du reproduserer noe: Android-versjon, produsent og modell, klientnavn og -versjon, profilen du valgte, nettverket du er tilkoblet, og klokketiden med tidssonen. Jeg noterer også om batterisparing eller Data Saver er på, fordi begge endrer hva klienten kan gjøre når skjermen slås av.

Deretter avgjør hvilket av fem utfall du faktisk ser på. Samtykke- eller tillatelsesforespørselen fullføres aldri, endepunktet kan ikke nås i det hele tatt, autentiseringen avvises, oppsettet av grensesnittet feiler etter vellykket innlogging, eller tunnelen kommer opp og én bestemt ressurs forblir utilgjengelig. Hver av dem har en annen eier og en annen løsning, og en pakke som blander dem får svar om å prøve igjen. Det er gjettingen mellom dem som gjør en times sak til en uke med frem og tilbake.

Overganger betyr også noe. Hvis feilen bare vises etter skjermlås eller etter et bytte fra Wi-Fi til mobildata, skriv det i første linje av saken og noter minuttet det skjedde.

Eksporter først klientens egen logg

Den første vedleggelsen bør komme fra appen og ikke fra operativsystemet. De fleste klienter tilbyr eksport av diagnostikk- eller tilkoblingslogg i innstillingene, noen ganger gjemt bak et langt trykk på versjonsstrengen, og den eksporten forstår allerede sin egen tilstandsmaskin. Bruk den slik den kommer ut i stedet for å skrive de interessante linjene inn i saken på nytt.

Legg ved den første feilen og hendelsene rett før den, ikke bare den siste linjen om brutt forbindelse. En ren hale betyr vanligvis at den egentlige feilen skjedde tidligere: en sertifikatkjede som ikke validerte, et navn som ble løst på et uventet sted, eller et grensesnitt som aldri ble konfigurert.

Legg bare til logcat for et spørsmål du kan navngi

En terminalemulator på telefonen er ikke en systemlogger. Android logger bufferne sine som separate sirkulære strømmer som bare privilegerte prosesser kan lese fullt ut. En vanlig app ser derfor sin egen utdata pluss en begrenset del, og påstanden om at logcat var tom beviser svært lite om hva plattformen registrerte.

Den støttede veien er en autorisert ADB-økt fra en datamaskin du kontrollerer. Slå på utvikleralternativer og USB-feilsøking, koble til kabelen, og godta RSA-fingeravtrykkdialogen på enheten; hvis den forespørselen lukkes, feiler hver senere kommando med unauthorized og ingen opptak starter.

Bekreft at enheten virkelig er der før du bruker tid på et opptak. adb devices skal skrive ut serienummeret etterfulgt av ordet device, og alt som viser offline eller unauthorized trenger først kabelen, forespørselen eller driveren ordnet.

Når den er på listen, begynn å ta opp noen sekunder før du trykker Connect og stopp rett etter at klienten gir opp. Et live-opptak med en bevisst start slår en dump tatt tjue minutter senere, fordi sirkelbufferne allerede har rotert og de tidlige linjene du trenger kan være borte:

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

Filtrer på tid og tag i stedet for ordet VPN

Å søke gjennom et opptak etter vpn er den raskeste måten å miste linjen som forklarer feilen. Sertifikatvalidering, prosesskrasj og endringer i tilkoblingen logges under tagger som aldri nevner VPN, så et nøkkelordfilter beholder støyen og kaster beviset.

Begrens først vinduet, deretter prioriteten, deretter taggen. Når du bare trenger det som skjedde etter et kjent tidspunkt, spiller adb logcat -v threadtime -t '11-03 20:14:00.000' av den nyeste halen fra det punktet, og formatet threadtime holder tidsstempler sammenlignbare med klientens egen eksport.

Hvis du kjenner klientpakken, følg prosessen i stedet for å gjette på tagger. adb shell pidof com.vendor.client returnerer en PID, og adb logcat --pid=1234 -v threadtime skriver bare ut den prosessen, mens adb logcat -g viser hvor mye plass hver buffer har før den begynner å overskrive.

Skjul hemmeligheter, og overlever deretter én sammenhengende pakke

Før noe forlater maskinen din, fjern passord, tokens, private nøkler, sesjonscookies og fullstendige enhetsidentifikatorer. Behold feilkodene, rekkefølgen av hendelser og adresseforholdene som gjør feilen lesbar, fordi et opptak som er ryddet forbi det punktet er like ubrukelig som et som aldri ble filtrert.

Send deretter én pakke i stedet for flere løse filer: klientens eksport, ADB-vinduet navngitt med start- og stopptid, et tolinjers sammendrag av trinnet som feilet, og miljønotatet fra toppen av denne listen. Hvis en del ikke kan publiseres offentlig, bruk leverandørens private støtteenkanal og si hvilken fil som trenger den kanalen.

Før du sender, sjekk fire ting. Dekker pakken ett forsøk i stedet for en hel ettermiddag? Overlapper klientens og systemets tidsstempler? Og inneholder den fortsatt et token, et passord eller en fullstendig abonnentidentifikator? Rett det siste punktet først, og legg deretter filene ved den eksisterende saken i stedet for å åpne en ny, slik at den som tar den over beholder den tidligere konteksten.