Ako zhromaždiť protokoly VPN Androidu pre tiket podpory

Klepnete na Connect, profil sa na sekundu točí a klient hlási odpojenie. Podpora žiada protokoly, vy priložíte snímku obrazovky a vlákno na dva dni zamrzne, pretože nikto nevie povedať, ktorá časť handshaku to vzdala. Správa postavená okolo jedného pokusu, s úzkym časovým oknom a poslednou dokončenou fázou, posunie tiket o kolo ďalej. Alternatíva, celý deň telefónnych protokolov, zvyčajne dá človeku na druhej strane viac miest, kam sa pozerať.

Dva telefóny na tej istej bráne sa môžu správať rôzne, pretože protokol, úložisko certifikátov, spôsob overovania alebo politika prevádzky nemusia súhlasiť. Funguje to na mojom telefóne je východiskové porovnanie, nie dôkaz o zlyhaní Androidu.

Zachyťte jeden pokus namiesto celého dňa histórie

Zapíšte prostredie, kým čokoľvek zopakujete: verzia Androidu, výrobca a model, názov a verzia klienta, zvolený profil, sieť, ku ktorej ste pripojení, a čas hodín s časovým pásmom. Zapisujem aj to, či je zapnutá úspora batérie alebo Data Saver, pretože obe menia, čo klient smie robiť po vypnutí obrazovky.

Potom určte, ktorý z piatich výsledkov skutočne vidíte. Výzva na súhlas alebo povolenie sa nikdy nedokončí, koncový bod je úplne nedostupný, overenie je odmietnuté, nastavenie rozhrania zlyhá po úspešnom prihlásení, alebo tunel naskočí a jeden konkrétny zdroj zostane nedostupný. Každý má iného vlastníka a inú opravu a balík, ktorý ich zmieša, dostane odpoveď so žiadosťou o nový pokus. Práve hádanie medzi nimi mení hodinový tiket na týždeň dopisovania.

Prechody sú tiež dôležité. Ak sa zlyhanie objaví len po zamknutí obrazovky alebo po prechode z Wi-Fi na mobilné dáta, napíšte to do prvého riadku tiketu a poznamenajte minútu, kedy sa to stalo.

Najprv exportujte vlastný protokol klienta

Prvá príloha by mala prísť z aplikácie, nie z operačného systému. Väčšina klientov má v nastaveniach export diagnostického alebo spojovacieho protokolu, niekedy skrytý za dlhým stlačením textu verzie, a tento export už rozumie svojmu stavovému automatu. Použite ho tak, ako vyjde, namiesto prepisovania zaujímavých riadkov do tela tiketu.

Priložte prvú chybu a udalosti tesne pred ňou, nie iba záverečný riadok o odpojení. Čistý koniec zvyčajne znamená, že skutočná porucha nastala skôr: reťaz certifikátov, ktorý sa neoveril, názov preložený na nečakanom mieste alebo rozhranie, ktoré nikdy nebolo nakonfigurované.

Pridajte logcat iba pre otázku, ktorú viete pomenovať

Emulátor terminálu v telefóne nie je systémový záznamník. Android zaznamenáva svoje buffery ako oddelené kruhové toky, ktoré môže plne čítať len privilegovaný proces. Bežná aplikácia teda vidí svoj výstup plus obmedzený výrez, a tvrdenie, že logcat bol prázdny, dokazuje len veľmi málo o tom, čo platforma zaznamenala.

Podporovaná cesta je autorizovaná relácia ADB z počítača, ktorý ovládate. Zapnite možnosti pre vývojárov a ladenie USB, pripojte kábel a prijmite dialóg s odtlačkom RSA v zariadení; ak sa tento dotaz zavrie, každý ďalší príkaz zlyhá s unauthorized a žiadne zachytávanie sa nezačne.

Predtým, než do zachytávania investujete čas, overte, či zariadenie naozaj je tam. adb devices má vypísať sériové číslo a za ním slovo device, a čokoľvek, čo ukazuje offline alebo unauthorized, potrebuje najprv vyriešiť kábel, dotaz alebo ovládač.

Keď sa objaví v zozname, začnite zachytávať niekoľko sekúnd pred klepnutím na Connect a zastavte hneď po tom, ako klient rezignuje. Živé zachytávanie s vedomým začiatkom je lepšie ako výpis urobený o dvadsať minút neskôr, pretože kruhové buffery sa už pretočili a rané riadky, ktoré potrebujete, môžu byť preč:

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

Filtrujte podľa času a značky, nie podľa slova VPN

Hľadať v zázname vpn je najrýchlejší spôsob, ako stratiť riadok, ktorý poruchu vysvetľuje. Overovanie certifikátov, pády procesov a zmeny pripojenia sa zaznamenávajú pod značkami, ktoré VPN nikdy nespomenú, takže filter podľa kľúčového slova podrží šum a zahodí dôkazy.

Najprv zúžte okno, potom prioritu, potom značku. Keď potrebujete len to, čo sa stalo po známom okamihu, adb logcat -v threadtime -t '11-03 20:14:00.000' prehrá nedávny koniec od tohto bodu a formát threadtime udrží časové značky porovnateľné s vlastným exportom klienta.

Ak poznáte balík klienta, sledujte jeho proces namiesto hádania značiek. adb shell pidof com.vendor.client vráti PID a adb logcat --pid=1234 -v threadtime vypíše len tento proces, zatiaľ čo adb logcat -g ukazuje, koľko miesta má každý buffer, kým začne prepisovať.

Začiernite tajomstvá a potom odovzdajte jeden súvislý balík

Skôr než čokoľvek opustí váš počítač, odstráňte heslá, tokeny, súkromné kľúče, relačné cookies a úplné identifikátory zariadenia. Ponechajte kódy chýb, poradie udalostí a vzťahy adries, ktoré robia poruchu čitateľnou, pretože záznam vyčistený za touto hranicou je rovnako zbytočný ako ten, ktorý sa nikdy nefiltroval.

Potom pošlite jeden balík namiesto niekoľkých voľných súborov: export klienta, okno ADB pomenované podľa začiatku a konca, dvojriadkové zhrnutie fázy, ktorá zlyhala, a poznámku o prostredí z hornej časti tohto zoznamu. Ak časť nemožno zverejniť verejne, použite súkromný kanál podpory poskytovateľa a povedzte, ktorý súbor ten kanál potrebuje.

Pred odoslaním skontrolujte štyri veci. Pokrýva balík jeden pokus a nie celé popoludnie? Prekrývajú sa časové značky klienta a systému? A obsahuje ešte token, heslo alebo úplný identifikátor predplatiteľa? Najprv opravte tento posledný bod, potom priložte súbory k existujúcemu tiketu namiesto otvárania nového, aby ten, kto ho prevezme, zachoval predchádzajúci kontext.