Paano kumulekta ng mga log ng VPN sa Android para sa tiket ng suporta

Pindutin mo ang Connect, umiikot ang profile nang isang segundo, at iniulat ng kliyente ang pagkadiskonekta. Humihingi ng log ang suporta, magkakabit ka ng screenshot, at natigil ang thread nang dalawang araw dahil walang makapagsabi kung aling bahagi ng handshake ang sumuko. Ang ulat na binuo sa isang pagtatangka, may makitid na window ng oras at ang huling natapos na yugto, ay nagpapausad sa tiket sa isang ikot. Ang alternatibo, isang buong araw ng mga log ng telepono, ay karaniwang nagbibigay sa kabilang panig ng mas maraming lugar na titingnan.

Dalawang telepono sa parehong gateway ay maaari pa ring magkaiba ang ugali, dahil ang protocol, imbakan ng sertipiko, paraan ng pagpapatotoo o patakaran sa trapiko ay maaaring hindi magtugma. Gumagana sa telepono ko ay isang panimulang paghahambing, hindi ebidensya ng pagkabigo ng Android.

Kunin ang isang pagtatangka sa halip na isang araw na kasaysayan

Isulat ang kapaligiran bago i-reproduce ang anuman: bersyon ng Android, tagagawa at modelo, pangalan at bersyon ng kliyente, ang profile na pinili mo, ang network na konektado ka, at ang oras ng relo kasama ang timezone nito. Itinatala ko rin kung naka-on ang tipid-baterya o Data Saver, dahil parehong binabago nila ang maaaring gawin ng kliyente kapag patay ang screen.

Pagkatapos ay magpasya kung alin sa limang kinalabasan ang talagang tinitingnan mo. Ang prompt ng pahintulot ay hindi kailanman natatapos, ang endpoint ay hindi maabot talaga, tinatanggihan ang pagpapatotoo, nabibigo ang setup ng interface pagkatapos ng matagumpay na pag-login, o umaangat ang tunnel at isang partikular na resource ang nananatiling hindi maabot. Bawat isa ay may ibang may-ari at ibang lunas, at ang bundle na naghahalo sa kanila ay nakakakuha ng sagot na subukan muli. Ang paghula sa pagitan nila ang nagiging sanhi ng isang oras na tiket na maging isang linggong palitan ng sulat.

Mahalaga rin ang mga transition. Kung lumalabas lamang ang pagkabigo pagkatapos ng screen lock o pagkatapos ng paglipat mula Wi-Fi patungong mobile data, isulat iyon sa unang linya ng tiket at itala ang minutong nangyari ito.

I-export muna ang sariling log ng kliyente

Ang unang attachment ay dapat magmula sa app at hindi sa operating system. Karamihan sa mga kliyente ay may export ng diagnostic o connection log sa settings, kung minsan nakatago sa likod ng mahabang pagpindot sa version string, at nauunawaan na ng export na iyon ang sarili nitong state machine. Gamitin ito kung paano ito lumalabas sa halip na i-type muli ang mga kawili-wiling linya sa katawan ng tiket.

Ikabit ang unang error at ang mga pangyayari kaagad bago iyon, hindi lamang ang huling linya ng pagkadiskonekta. Ang malinis na buntot ay karaniwang nangangahulugan na ang tunay na pagkabigo ay nangyari nang mas maaga: isang chain ng sertipiko na hindi nagpapatunay, isang pangalang naresolba sa hindi inaasahang lugar, o isang interface na hindi kailanman na-configure.

Magdagdag ng logcat para lamang sa tanong na kayang pangalanan

Ang terminal emulator sa telepono ay hindi system logger. Itinatala ng Android ang mga buffer nito bilang hiwalay na pabilog na stream na tanging mga prosesong may pribilehiyo ang makababasa nang buo. Kaya ang ordinaryong app ay nakakakita ng sarili nitong output at isang limitadong bahagi, at ang pahayag na walang laman ang logcat ay nagpapatunay ng napakakaunti tungkol sa kung ano ang naitala ng platform.

Ang sinusuportahang landas ay isang awtorisadong sesyon ng ADB mula sa kompyuter na kinokontrol mo. I-on ang mga opsyon ng developer at USB debugging, ikabit ang cable, at tanggapin ang dialog ng RSA fingerprint sa device; kung isasara ang prompt na iyon, bawat kasunod na utos ay mabibigo gamit ang unauthorized at walang pagkuha ang magsisimula.

Kumpirmahin na talagang naroon ang device bago maglaan ng oras sa pagkuha. Dapat i-print ng adb devices ang serial number at pagkatapos ang salitang device, at anumang nagpapakita ng offline o unauthorized ay kailangan munang ayusin ang cable, prompt o driver.

Kapag nakalista na, simulan ang pagkuha ng ilang segundo bago pindutin ang Connect at itigil kaagad pagkatapos sumuko ng kliyente. Ang live na pagkuha na may sadyang simula ay mas mahusay kaysa sa dump na kinuha dalawampung minuto mamaya, dahil umikot na ang mga pabilog na buffer at ang mga unang linyang kailangan mo ay maaaring nawala na:

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

I-filter ayon sa oras at tag sa halip na sa salitang VPN

Ang paghahanap ng vpn sa isang pagkuha ay ang pinakamabilis na paraan upang mawala ang linyang nagpapaliwanag ng pagkabigo. Ang pagpapatunay ng sertipiko, pag-crash ng proseso at pagbabago ng konektibidad ay naitala sa ilalim ng mga tag na hindi kailanman nagbabanggit ng VPN, kaya pinapanatili ng filter ng keyword ang ingay at itinatapon ang ebidensya.

Paliitin muna ang window, pagkatapos ang priyoridad, pagkatapos ang tag. Kapag kailangan mo lamang ang nangyari pagkatapos ng kilalang sandali, muling pinapatugtog ng adb logcat -v threadtime -t '11-03 20:14:00.000' ang kamakailang buntot mula sa puntong iyon, at pinapanatili ng format na threadtime ang mga timestamp na maihahambing sa sariling export ng kliyente.

Kung alam mo ang pakete ng kliyente, sundan ang proseso nito sa halip na hulaan ang mga tag. Nagbabalik ng PID ang adb shell pidof com.vendor.client at ang adb logcat --pid=1234 -v threadtime ay nagpi-print lamang ng prosesong iyon, habang ang adb logcat -g ay nagpapakita kung gaano karaming espasyo mayroon ang bawat buffer bago ito magsimulang mag-overwrite.

Itago ang mga lihim, pagkatapos ay ibigay ang isang magkakaugnay na bundle

Bago umalis ang anuman sa iyong makina, alisin ang mga password, token, pribadong key, session cookie at kumpletong identifier ng device. Panatilihin ang mga error code, pagkakasunod-sunod ng mga pangyayari at mga ugnayan ng address na nagpapabasa ng pagkabigo, dahil ang pagkuha na nilinis lampas sa puntong iyon ay kasing walang silbi ng hindi kailanman na-filter.

Pagkatapos ay magpadala ng isang bundle sa halip na maraming malalayang file: ang export ng kliyente, ang window ng ADB na pinangalanan sa oras ng pagsisimula at pagtigil, isang dalawang-linyang buod ng yugtong nabigo, at ang tala ng kapaligiran mula sa itaas ng listahang ito. Kung may bahaging hindi maipost sa publiko, gamitin ang pribadong channel ng suporta ng provider at sabihin kung aling file ang nangangailangan ng channel na iyon.

Bago magpadala, suriin ang apat na bagay. Saklaw ba ng bundle ang isang pagtatangka at hindi ang buong hapon? Nag-o-overlap ba ang mga timestamp ng kliyente at system? At mayroon pa bang token, password o kumpletong identifier ng subscriber? Ayusin muna ang huling puntong iyon, pagkatapos ay ikabit ang mga file sa umiiral na tiket sa halip na magbukas ng bago, upang mapanatili ng kukuha nito ang naunang konteksto.