سپورٹ ٹکٹ کے لیے Android پر VPN لاگز کیسے جمع کریں

آپ Connect دباتے ہیں، پروفائل ایک سیکنڈ گھومتا ہے اور کلائنٹ رابطہ منقطع ہونے کی اطلاع دیتا ہے۔ سپورٹ لاگ مانگتی ہے، آپ اسکرین شاٹ منسلک کرتے ہیں، اور تھریڈ دو دن رکا رہتا ہے کیونکہ کوئی نہیں بتا سکتا کہ ہینڈ شیک کا کون سا حصہ ہار گیا۔ ایک کوشش کے گرد بنی رپورٹ، تنگ وقتی ونڈو اور مکمل شدہ آخری مرحلے کے ساتھ، ٹکٹ کو ایک ہی چکر میں آگے بڑھاتی ہے۔ متبادل، یعنی پورے دن کے فون لاگ، عام طور پر دوسری طرف کے شخص کو دیکھنے کے لیے زیادہ جگہیں دیتے ہیں۔

ایک ہی گیٹ وے پر دو فون مختلف برتاؤ کر سکتے ہیں، کیونکہ پروٹوکول، سرٹیفکیٹ اسٹور، توثیق کا طریقہ یا ٹریفک پالیسی میل نہ کھا سکے۔ میرے فون پر چلتا ہے یہ موازنے کا آغاز ہے، Android خرابی کا ثبوت نہیں۔

پورے دن کی تاریخ کی بجائے ایک کوشش قید کریں

کچھ بھی دہرانے سے پہلے ماحول لکھ لیں: Android ورژن، بنانے والا اور ماڈل، کلائنٹ کا نام اور ورژن، آپ کا منتخب کردہ پروفائل، جس نیٹ ورک سے جڑے ہیں، اور ٹائم زون کے ساتھ گھڑی کا وقت۔ میں یہ بھی نوٹ کرتا ہوں کہ بیٹری سیور یا Data Saver آن ہے یا نہیں، کیونکہ دونوں اسکرین بند ہونے کے بعد کلائنٹ کیا کر سکتا ہے یہ بدلتے ہیں۔

پھر طے کریں کہ پانچ نتائج میں سے آپ واقعی کون سا دیکھ رہے ہیں۔ رضامندی یا اجازت کا پرامپٹ کبھی مکمل نہیں ہوتا، آخری نقطہ تک پہنچا ہی نہیں جا سکتا، توثیق مسترد ہوتی ہے، کامیاب لاگ ان کے بعد انٹرفیس سیٹ اپ ناکام ہوتا ہے، یا ٹنل اوپر آتا ہے اور ایک مخصوص وسیلہ ناقابل رسائی رہتا ہے۔ ہر ایک کا مالک اور حل الگ ہے، اور انہیں ملا دینے والا بنڈل دوبارہ کوشش کرنے کا جواب پاتا ہے۔ ان کے درمیان اندازہ لگانا ہی ایک گھنٹے کے ٹکٹ کو ایک ہفتے کے خط و کتابت میں بدلتا ہے۔

تبدیلیاں بھی اہم ہیں۔ اگر خرابی صرف اسکرین لاک کے بعد یا Wi-Fi سے موبائل ڈیٹا پر جانے کے بعد ظاہر ہو، تو اسے ٹکٹ کی پہلی سطر میں لکھیں اور وہ منٹ نوٹ کریں جب ایسا ہوا۔

پہلے کلائنٹ کا اپنا لاگ برآمد کریں

پہلا منسلکہ ایپ سے آنا چاہیے، آپریٹنگ سسٹم سے نہیں۔ زیادہ تر کلائنٹ سیٹنگز میں تشخیصی یا کنکشن لاگ کی برآمد دیتے ہیں، کبھی کبھی ورژن اسٹرنگ پر طویل دباؤ کے پیچھے چھپا ہوتا ہے، اور وہ برآمد اپنی حالت مشین پہلے ہی سمجھتی ہے۔ دلچسپ سطروں کو ٹکٹ کے متن میں دوبارہ ٹائپ کرنے کی بجائے اسے ویسے ہی استعمال کریں جیسے آتا ہے۔

پہلی خرابی اور اس سے فوراً پہلے کے واقعات منسلک کریں، صرف آخری منقطع ہونے کی سطر نہیں۔ صاف دُم عام طور پر یہ معنی رکھتی ہے کہ اصل خرابی پہلے واقع ہوئی: ایسا سرٹیفکیٹ سلسلہ جو تصدیق نہ ہوا، ایسا نام جو غیر متوقع جگہ حل ہوا، یا ایسا انٹرفیس جو کبھی ترتیب نہ دیا گیا۔

logcat صرف اس سوال کے لیے شامل کریں جس کا نام آپ بتا سکیں

فون پر ٹرمینل ایمولیٹر سسٹم لاگر نہیں ہے۔ Android اپنے بفرز الگ گولائی دار اسٹریمز کے طور پر ریکارڈ کرتا ہے، جنہیں مکمل طور پر صرف مراعات یافتہ پروسیس پڑھ سکتے ہیں۔ اس لیے ایک عام ایپ اپنا آؤٹ پٹ اور ایک محدود حصہ دیکھتی ہے، اور یہ کہنا کہ logcat خالی تھا پلیٹ فارم نے کیا ریکارڈ کیا اس بارے میں بہت کم ثابت کرتا ہے۔

معاون راستہ آپ کے زیرِ کنٹرول کمپیوٹر سے مجاز ADB سیشن ہے۔ ڈویلپر آپشنز اور USB ڈیبگنگ آن کریں، کیبل جوڑیں، اور ڈیوائس پر RSA فنگر پرنٹ ڈائیلاگ قبول کریں؛ اگر وہ پرامپٹ بند کر دیا جائے تو ہر اگلا کمانڈ unauthorized کے ساتھ ناکام ہوتا ہے اور کوئی کیپچر شروع نہیں ہوتا۔

کیپچر میں وقت لگانے سے پہلے تصدیق کریں کہ ڈیوائس واقعی وہاں ہے۔ adb devices کو سیریل نمبر اور پھر device لفظ چھاپنا چاہیے، اور offline یا unauthorized دکھانے والی کسی بھی چیز کو پہلے کیبل، پرامپٹ یا ڈرائیور درست کرنے کی ضرورت ہے۔

فہرست میں آنے کے بعد، Connect دبانے سے چند سیکنڈ پہلے کیپچر شروع کریں اور کلائنٹ ہارنے کے فوراً بعد روکیں۔ جان بوجھ کر شروع کیا گیا براہ راست کیپچر بیس منٹ بعد لیے گئے ڈمپ سے بہتر ہے، کیونکہ گولائی دار بفر پہلے ہی گھوم چکے ہیں اور آپ کو درکار ابتدائی سطریں جا چکی ہو سکتی ہیں:

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

VPN لفظ کی بجائے وقت اور ٹیگ سے فلٹر کریں

کیپچر میں vpn تلاش کرنا اس سطر کو کھونے کا تیز ترین طریقہ ہے جو خرابی کی وضاحت کرتی ہے۔ سرٹیفکیٹ کی تصدیق، پروسیس کریش اور کنیکٹیویٹی کی تبدیلیاں ایسے ٹیگز کے تحت ریکارڈ ہوتی ہیں جو کبھی VPN کا ذکر نہیں کرتے، اس لیے کلیدی لفظ فلٹر شور رکھتا ہے اور ثبوت پھینک دیتا ہے۔

پہلے ونڈو، پھر ترجیح، پھر ٹیگ تنگ کریں۔ جب آپ کو صرف وہ چیز درکار ہو جو کسی معلوم لمحے کے بعد ہوئی، تو adb logcat -v threadtime -t '11-03 20:14:00.000' اسی نقطے سے حالیہ دُم دوبارہ چلاتا ہے، اور threadtime فارمیٹ ٹائم اسٹیمپ کو کلائنٹ کی اپنی برآمد کے ساتھ موازنے کے قابل رکھتا ہے۔

اگر آپ کلائنٹ پیکیج جانتے ہیں، تو ٹیگ کا اندازہ لگانے کی بجائے اس کے پروسیس کی پیروی کریں۔ adb shell pidof com.vendor.client ایک PID واپس کرتا ہے اور adb logcat --pid=1234 -v threadtime صرف اسی پروسیس کو چھاپتا ہے، جبکہ adb logcat -g دکھاتا ہے کہ ہر بفر کے پاس دوبارہ لکھنا شروع کرنے سے پہلے کتنی جگہ ہے۔

راز چھپائیں، پھر ایک مربوط بنڈل حوالے کریں

آپ کی مشین سے کچھ بھی نکلنے سے پہلے پاس ورڈ، ٹوکن، نجی کلیدیں، سیشن کوکیز اور مکمل ڈیوائس شناخت کنندگان ہٹا دیں۔ خرابی کو پڑھنے کے قابل بنانے والے ایرر کوڈز، واقعات کی ترتیب اور پتہ تعلقات رکھیں، کیونکہ اس حد سے آگے صاف کیا گیا کیپچر اتنے ہی بیکار ہے جتنا کبھی فلٹر نہ کیا گیا۔

پھر کئی الگ فائلوں کی بجائے ایک بنڈل بھیجیں: کلائنٹ کی برآمد، آغاز اور توقف کے وقت سے موسوم ADB ونڈو، ناکام مرحلے کا دو سطروں کا خلاصہ، اور اس فہرست کے اوپر سے ماحول کا نوٹ۔ اگر اس کا کوئی حصہ عوامی طور پر شائع نہیں ہو سکتا، تو فراہم کنندہ کا نجی سپورٹ چینل استعمال کریں اور بتائیں کہ کون سی فائل کو وہ چینل درکار ہے۔

بھیجنے سے پہلے چار چیزیں جانچیں۔ کیا بنڈل پوری دوپہر کی بجائے ایک کوشش کا احاطہ کرتا ہے؟ کیا کلائنٹ اور سسٹم کے ٹائم اسٹیمپ اوورلیپ کرتے ہیں؟ اور کیا اس میں اب بھی ٹوکن، پاس ورڈ یا مکمل صارف شناخت کنندہ موجود ہے؟ پہلے وہ آخری نکتہ درست کریں، پھر نئی ٹکٹ کھولنے کی بجائے موجودہ ٹکٹ میں فائلیں منسلک کریں، تاکہ اسے لینے والا پہلے کا سیاق برقرار رکھے۔