সাপোর্ট টিকিটের জন্য অ্যান্ড্রয়েডে VPN লগ কীভাবে সংগ্রহ করবেন

আপনি Connect চাপেন, প্রোফাইলটি এক সেকেন্ডের জন্য ঘোরে, এবং ক্লায়েন্ট জানায় সংযোগ বিচ্ছিন্ন হয়েছে। সাপোর্ট লগ চায়, আপনি একটি স্ক্রিনশট সংযুক্ত করেন, আর থ্রেডটি দুই দিন আটকে থাকে, কারণ হ্যান্ডশেকের কোন অংশটি হাল ছেড়েছে তা কেউ বলতে পারে না। একটি মাত্র প্রচেষ্টাকে ঘিরে গড়া রিপোর্ট, সংকীর্ণ সময়সীমা ও সর্বশেষ সম্পন্ন ধাপসহ, টিকিটটিকে এক রাউন্ডেই এগিয়ে নেয়। বিকল্পটি, অর্থাৎ পুরো এক দিনের ফোন লগ, সাধারণত অন্য প্রান্তের মানুষটিকে খোঁজার আরও বেশি জায়গা দেয়।

একই গেটওয়েতে থাকা দুটি ফোনও ভিন্নভাবে আচরণ করতে পারে, কারণ প্রোটোকল, সার্টিফিকেট স্টোর, প্রমাণীকরণ পদ্ধতি বা ট্রাফিক নীতি মিলতে নাও পারে। আমার ফোনে কাজ করে, এটি তুলনার সূচনা, অ্যান্ড্রয়েডের ব্যর্থতার প্রমাণ নয়।

এক দিনের ইতিহাসের বদলে একটি প্রচেষ্টা ধরুন

কিছু পুনরুৎপাদন করার আগে পরিবেশটি লিখে নিন: অ্যান্ড্রয়েড সংস্করণ, নির্মাতা ও মডেল, ক্লায়েন্টের নাম ও সংস্করণ, আপনি যে প্রোফাইল বেছেছেন, যে নেটওয়ার্কে সংযুক্ত আছেন, এবং টাইমজোনসহ ঘড়ির সময়। ব্যাটারি সেভার বা ডেটা সেভার চালু আছে কি না তাও নোট করি, কারণ দুটোই স্ক্রিন বন্ধ হওয়ার পর ক্লায়েন্ট কী করতে পারবে তা বদলে দেয়।

তারপর নির্ধারণ করুন আপনি পাঁচটি ফলাফলের মধ্যে কোনটি দেখছেন। সম্মতি বা অনুমতির প্রম্পট কখনও সম্পূর্ণ হয় না, এন্ডপয়েন্টে আদৌ পৌঁছানো যায় না, প্রমাণীকরণ প্রত্যাখ্যাত হয়, সফল লগইনের পর ইন্টারফেস সেটআপ ব্যর্থ হয়, অথবা টানেল উঠে আসে কিন্তু একটি নির্দিষ্ট রিসোর্স অধরা থাকে। প্রত্যেকটির মালিক আলাদা ও সমাধান আলাদা, আর যেসব বান্ডেল এগুলো মিশিয়ে দেয় সেগুলো আবার চেষ্টা করার অনুরোধপূর্ণ উত্তর পায়। এগুলোর মধ্যে অনুমান করাই এক ঘণ্টার টিকিটকে এক সপ্তাহের চিঠাচালিতে পরিণত করে।

ট্রানজিশনও গুরুত্বপূর্ণ। যদি ব্যর্থতা কেবল স্ক্রিন লক হওয়ার পর বা Wi-Fi থেকে মোবাইল ডেটায় হাতবদলের পর দেখা যায়, তবে সেটি টিকিটের প্রথম লাইনে লিখুন এবং কোন মিনিটে ঘটেছে তা নোট করুন।

প্রথমে ক্লায়েন্টের নিজস্ব লগ রপ্তানি করুন

প্রথম সংযুক্তিটি অপারেটিং সিস্টেম থেকে নয়, অ্যাপ থেকেই আসা উচিত। বেশিরভাগ ক্লায়েন্ট সেটিংসে ডায়াগনস্টিক বা সংযোগ-লগ রপ্তানি দেয়, মাঝে মাঝে সংস্করণ স্ট্রিংয়ের উপর দীর্ঘ চাপ দিয়ে লুকানো থাকে, এবং সেই রপ্তানি নিজের স্টেট মেশিন বোঝে। আগ্রহের লাইনগুলো টিকিটের শরীরে আবার টাইপ করার বদলে যেভাবে আসে সেভাবেই ব্যবহার করুন।

প্রথম ত্রুটি এবং ঠিক তার আগের ঘটনাগুলো সংযুক্ত করুন, শুধু শেষ বিচ্ছিন্নতার লাইন নয়। পরিষ্কার লেজ সাধারণত বোঝায় আসল ব্যর্থতা আগেই ঘটেছে: যে সার্টিফিকেট চেইন যাচাই হয়নি, যে নাম অপ্রত্যাশিত জায়গায় রিজলভ হয়েছে, বা যে ইন্টারফেস কখনও কনফিগার হয়নি।

logcat যোগ করুন কেবল এমন প্রশ্নের জন্য যার নাম আপনি বলতে পারেন

ফোনের টার্মিনাল এমুলেটর কোনো সিস্টেম লগার নয়। অ্যান্ড্রয়েড তার বাফারগুলো আলাদা বৃত্তাকার স্ট্রিম হিসেবে লেখে, যা কেবল বিশেষাধিকারপ্রাপ্ত প্রসেসই সম্পূর্ণ পড়তে পারে। তাই সাধারণ অ্যাপ নিজের আউটপুট আর একটি সীমিত অংশ দেখে, আর 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 উইন্ডো, যে ধাপটি ব্যর্থ হয়েছে তার দুই লাইনের সারাংশ, এবং এই তালিকার শুরুর পরিবেশ-নোট। এর কোনো অংশ প্রকাশ্যে পোস্ট করা না গেলে সরবরাহকারীর ব্যক্তিগত সাপোর্ট চ্যানেল ব্যবহার করুন এবং কোন ফাইলের সেই চ্যানেল দরকার তা বলুন।

পাঠানোর আগে চারটি জিনিস যাচাই করুন। বান্ডেলটি কি পুরো এক বিকেলের বদলে একটি প্রচেষ্টা কভার করে? ক্লায়েন্ট ও সিস্টেমের টাইমস্ট্যাম্প কি ওভারল্যাপ করে? আর এতে কি এখনও কোনো টোকেন, পাসওয়ার্ড বা সম্পূর্ণ গ্রাহক শনাক্তকারী আছে? আগে এই শেষ বিষয়টি ঠিক করুন, তারপর নতুন টিকিট না খুলে বিদ্যমান টিকিটে ফাইলগুলো সংযুক্ত করুন, যাতে যে এটি হাতে নেয় সে আগের প্রসঙ্গ ধরে রাখতে পারে।