Cynthion چه مسئله‌ای را حل می‌کند؟
وقتی یک وسیله USB گاهی شناسایی می‌شود و گاهی نه، گزارش برنامه کاربردی معمولاً تصویر کاملی از مشکل ندارد. برنامه ممکن است فقط قطع ارتباط را ببیند، در حالی که علت در توصیفگر دستگاه، ترتیب درخواست‌های کنترلی، زمان پاسخ یا تعامل میزبان و وسیله نهفته است. Cynthion محصول Great Scott Gadgets برای مشاهده و آزمایش همین لایه ارتباطی ساخته شده است. کاربرد اصلی آن در این معرفی، کمک به توسعه‌دهنده سخت‌افزار و Firmware برای فهم رفتار واقعی USB در آزمایشگاه است. ارزش ابزار وقتی آشکار می‌شود که بتوان به جای حدس درباره آنچه در کابل رخ می‌دهد، یک ثبت قابل بررسی از تبادل‌ها داشت.
طبق صفحه رسمی Cynthion، این دستگاه یک سکوی مبتنی بر FPGA است و می‌تواند ترافیک USB با سرعت‌های Low، Full و High را تحلیل کند. نرم‌افزار Packetry برای تحلیل ثبت‌ها معرفی شده و پروژه‌های LUNA و Facedancer مسیر توسعه و آزمایش دستگاه‌های USB را تکمیل می‌کنند. این عبارت‌ها را نباید به پشتیبانی از تمام نسل‌های USB تعبیر کرد: High-Speed در این زمینه به خانواده USB 2.0 مربوط است و جای تحلیلگر اختصاصی پیوند SuperSpeed را نمی‌گیرد. شکل کانکتور نیز به تنهایی سرعت یا قابلیت پروتکل را تعیین نمی‌کند.
تفاوت مشاهده بسته با بررسی شکل موج
تحلیلگر پروتکل به شما کمک می‌کند بفهمید کدام درخواست ارسال شده، چه پاسخی رسیده و گفتگو در کدام مرحله متوقف شده است. اسیلوسکوپ، در مقابل، برای سؤال‌هایی مانند کیفیت سیگنال، دامنه، نویز و حاشیه زمانی مناسب‌تر است. اگر بسته‌ای هرگز به صورت قابل تفسیر دریافت نشود، مشاهده نرم‌افزاری ممکن است فقط غیبت آن را نشان دهد. نتیجه درست این نیست که Firmware حتماً خراب است؛ کابل، اتصال، تغذیه و کیفیت مسیر نیز فرضیه‌های معتبر هستند. در یک میز آزمایش کامل، این دو نوع مشاهده مکمل یکدیگرند و باید بدانیم هر کدام چه چیزی را نمی‌بینند.
نمونه ساده، وسیله‌ای است که پس از اتصال به هاب از کار می‌افتد. ابتدا می‌توان ثبت مستقیم و ثبت از طریق هاب را مقایسه کرد و مرحله واگرایی را یافت. اگر تفاوت در توصیفگر یا پاسخ کنترل دیده شود، تحقیق نرم‌افزاری جهت پیدا می‌کند. اگر ارتباط پیش از آن ناپایدار باشد، آزمایش با کابل و تغذیه متفاوت ضروری است. این ترتیب کار مانع می‌شود ساعت‌ها کد تغییر کند، در حالی که ایراد از یک مسیر فیزیکی ضعیف بوده است. Cynthion در این فرایند شاهد رخدادهاست؛ نتیجه‌گیری همچنان به طراحی آزمایش وابسته است.
جایگاه FPGA و نرم‌افزارهای همراه
وجود FPGA به این معناست که بخشی از رفتار دیجیتال ابزار را می‌توان با طراحی منطقی تغییر داد. برای کاربر تازه‌کار لازم نیست نخست از طراحی مدار دیجیتال آغاز شود؛ استفاده از نرم‌افزار تحلیل رسمی نقطه شروع مناسب‌تری است. بعد از تسلط بر ثبت و تفسیر، توسعه‌دهنده می‌تواند سراغ قابلیت‌های پیشرفته‌تر برود. باید میان Firmware کنترل دستگاه، Gateware داخل FPGA و برنامه میزبان تمایز گذاشت. ناسازگاری نسخه‌های این اجزا ممکن است ظاهری شبیه خرابی سخت‌افزار ایجاد کند، بنابراین نسخه هر سه باید در پرونده آزمایش ثبت شود.
LUNA برای کار روی منطق USB و Facedancer برای ساخت رفتار دستگاه با کمک نرم‌افزار کاربرد دارند. این ابزارها امکان تدوین نمونه آزمایشی را فراهم می‌کنند، اما نمونه‌ای که در آزمایشگاه پاسخ می‌دهد الزاماً محصول قابل عرضه نیست. مدیریت خطا، رفتار هنگام قطع برق، وضعیت‌های تعلیق، سازگاری با چند میزبان و تحمل ترتیب‌های متفاوت درخواست نیز باید بررسی شوند. بهتر است توسعه در گام‌های کوچک انجام شود: نخست شناسایی درست، سپس یک مسیر تبادل ساده و در نهایت حالت‌های نامعمول. تغییر همزمان چند ویژگی تفسیر نتیجه را دشوار می‌کند.
یک تمرین عملی برای دستگاه تحت مالکیت
فرض کنید یک برد آموزشی دارید که باید به عنوان رابط سریال USB شناسایی شود. هدف تمرین، مقایسه نسخه پایدار Firmware با نسخه جدید است. پیش از اتصال، هر دو فایل ساخت را نام‌گذاری کنید و شناسه نسخه، سیستم‌عامل میزبان، کابل و تنظیمات پروژه را یادداشت کنید. ابتدا با نسخه پایدار ثبت بگیرید تا بدانید توالی سالم چه شکلی دارد. سپس همان آزمایش را با نسخه جدید و بدون تغییر دیگر تکرار کنید. این ثبت پایه اجازه می‌دهد هر تفاوت را به تغییر نرم‌افزار نسبت دهید، البته فقط تا جایی که سایر شرایط واقعاً ثابت مانده‌اند.
به جای جستجوی تصادفی در همه بسته‌ها، سؤال مشخص انتخاب کنید: آیا میزبان توصیفگر پیکربندی را دریافت می‌کند؟ آیا دستگاه پس از انتخاب پیکربندی پاسخ می‌دهد؟ آیا تبادل داده شروع می‌شود و سپس متوقف می‌گردد؟ پاسخ هر سؤال یک مرحله از مسیر عیب‌یابی را حذف یا تأیید می‌کند. اگر رفتار نامنظم است، چند اجرای کوتاه از یک اجرای بسیار طولانی مفیدتر خواهد بود؛ مقایسه زمان شروع و نقطه شکست آسان‌تر می‌شود. خروجی این تمرین باید شامل ثبت سالم، ثبت معیوب و توضیح دقیق نخستین تفاوت معنادار باشد.
خواندن خطا بدون نتیجه‌گیری عجولانه
هر پاسخ غیرعادی لزوماً نقص امنیتی نیست. ممکن است درخواست میزبان با قابلیت اعلام‌شده دستگاه سازگار نباشد یا برنامه در حال بستن رابط باشد. همچنین عدم مشاهده یک تبادل، به تنهایی ثابت نمی‌کند که میزبان آن را درخواست نکرده است؛ کیفیت ثبت و محدودیت مسیر ضبط باید بررسی شود. هنگام نوشتن گزارش، عبارت «در این ثبت مشاهده نشد» دقیق‌تر از «هرگز رخ نمی‌دهد» است. این تفاوت زبانی کوچک، گزارش را برای مهندسی که باید مسئله را بازتولید کند بسیار قابل اعتمادتر می‌سازد.
برای یک ایراد تکرارشونده، رویدادها را به زبان محصول هم ترجمه کنید. مثلاً توضیح دهید که کاربر پس از اتصال مجدد مجبور به راه‌اندازی دوباره برنامه می‌شود و سپس شواهد پروتکلی را ارائه کنید. گزارش صرفاً شامل فهرست بسته‌ها برای تصمیم‌گیرنده قابل استفاده نیست. باید روشن باشد خطا چه اثری دارد، با چه شرایطی رخ می‌دهد و کدام اصلاح پیشنهادی آن را رفع می‌کند. ثبت خام ضمیمه گزارش است؛ استدلال مهندسی از ارتباط میان شواهد و تجربه کاربر به دست می‌آید.
طراحی آزمون‌های منفی کنترل‌شده
در آزمایشگاه مجاز می‌توان رفتار دستگاه خود را در برابر ورودی‌های نامعتبر و ترتیب‌های غیرمنتظره درخواست بررسی کرد. هدف چنین آزمایشی باید یافتن توقف، نشت وضعیت یا بازیابی نامناسب در محصول تحت اختیار باشد. هر مورد آزمون باید از پیش تعریف شود و میزبان آزمایش از داده‌های مهم جدا باشد. این کار کمک می‌کند اگر دستگاه قفل شد یا سیستم‌عامل نیاز به بازیابی داشت، نتیجه آزمایش با خسارت عملیاتی همراه نشود. نخست وضعیت سالم و روش برگشت به آن را مستند کنید؛ سپس تنها یک مؤلفه ورودی را تغییر دهید.
موفقیت آزمون منفی به معنای ایجاد بیشترین آشفتگی نیست. معیار مناسب این است که وسیله خطا را تشخیص دهد، وضعیت داخلی را سالم نگه دارد و پس از پایان شرایط نامعتبر به رفتار عادی برگردد. برای مثال، توقف موقت انتقال و بازگشت خودکار ممکن است قابل قبول باشد، در حالی که نیاز به قطع برق نشان‌دهنده ضعف بازیابی است. ثبت نتیجه باید میان خطای مورد انتظار، توقف غیرمنتظره و محدودیت خود محیط آزمون فرق بگذارد. بدین ترتیب ابزار به چرخه کیفیت محصول خدمت می‌کند و صرفاً نمایش قابلیت فنی نخواهد بود.
مدیریت داده و محرمانگی ثبت‌ها
ترافیک USB می‌تواند شامل داده کاربردی باشد. ثبت یک صفحه‌کلید، وسیله ذخیره‌سازی یا رابط مدیریتی ممکن است اطلاعاتی داشته باشد که در ظاهر پنجره تحلیل دیده نمی‌شود. بنابراین برای تمرین از داده ساختگی استفاده کنید و پیش از اشتراک فایل، محتوای آن را بررسی نمایید. حذف چند سطر از تصویر صفحه لزوماً داده خام را پاک نمی‌کند. اگر لازم است نمونه‌ای برای گزارش عمومی آماده شود، بازتولید مسئله با حداقل داده و کمترین تعداد تبادل، هم خوانایی را بهتر می‌کند و هم احتمال افشای ناخواسته را کاهش می‌دهد.
در تیم توسعه، محل نگهداری ثبت‌ها باید با همان دقت مخزن کد انتخاب شود. نام فایل شامل تاریخ، شناسه نمونه و نسخه نرم‌افزار باشد، اما اطلاعات مشتری در آن نیاید. برای هر ایراد فقط ثبت‌هایی را نگه دارید که به تصمیم فنی کمک می‌کنند. آرشیو انبوه بدون توضیح معمولاً بعد از چند هفته بی‌استفاده می‌شود. یک یادداشت کوتاه درباره هدف، مراحل و نتیجه هر ثبت، ارزش آن را بسیار بیشتر از حجم فایل بالا می‌برد و انتقال دانش میان اعضای تیم را آسان می‌کند.
هزینه یادگیری و انتخاب درست
Cynthion برای کسی که فقط می‌خواهد ولتاژ یک پایه را اندازه بگیرد انتخاب مستقیمی نیست. مزیت اصلی آن در مشاهده و ساخت رفتار USB است. اگر پروژه شما بر رابط‌های I2C یا SPI متمرکز است، تحلیلگر منطقی یا رابط توسعه مناسب ممکن است سریع‌تر پاسخ بدهد. همچنین اگر هدف صرفاً بررسی گزارش نرم‌افزار میزبان باشد، ابزارهای ثبت سیستم‌عامل می‌توانند مرحله نخست مناسبی باشند. خرید ابزار سخت‌افزاری وقتی توجیه پیدا می‌کند که محدودیت مشاهده در میزبان مانع پاسخ به سؤال واقعی پروژه شده باشد.
برای ارزیابی، یک ایراد واقعی و کوچک انتخاب کنید و بسنجید آیا ابزار زمان تشخیص را کاهش می‌دهد. هزینه کابل، میزبان مناسب، زمان آموزش و نگهداری نسخه‌ها را نیز حساب کنید. مستندات و مخزن رسمی در پروژه Cynthion نقطه مراجعه برای پشتیبانی و سازگاری هستند. تصمیم خوب بر اساس تعداد قابلیت‌های تبلیغاتی گرفته نمی‌شود؛ بر اساس این است که تیم بتواند از ثبت خام به یک اصلاح قابل آزمون برسد. اگر چنین گردش کاری شکل بگیرد، Cynthion می‌تواند بخش ماندگار آزمایشگاه توسعه USB باشد.
یک معیار روشن برای پایان بررسی
پایان عیب‌یابی را از ابتدا تعریف کنید. اگر ایراد قطع ارتباط پس از اتصال مجدد است، اصلاح باید در چند چرخه اتصال و جداسازی، با همان میزبان و سپس یک میزبان دیگر بررسی شود. تنها حذف پیام خطا کافی نیست؛ انتقال واقعی داده نیز باید درست بماند. برای تغییر توصیفگر، سازگاری برنامه‌های مصرف‌کننده را دوباره بسنجید. این بررسی از آن جلوگیری می‌کند که اصلاح یک مرحله، مرحله بعدی را خراب کند. پرونده نهایی بهتر است شامل فرضیه اولیه، شاهد رد یا تأیید، تغییر انجام‌شده و نتیجه آزمون بازگشت باشد. چنین پرونده‌ای ماه‌ها بعد هم قابل فهم است و در آموزش عضو جدید تیم به کار می‌آید. ارزش ثبت پروتکل دقیقاً در همین پیوند میان مشاهده، اصلاح و تأیید دوباره آشکار می‌شود.
