الخلاصة

  • غطّى FCS في PPP حقول الإطار المحددة، لا رايات الفصل ولا بتات البدء والتوقف ولا ما أُدخل من أجل الشفافية. أجرى المرسل الحشو بعد الحساب، وألغاه المستقبل قبل الفحص.
  • سمحت ACCM المستقبلة بحذف محارف مختارة فقط تقل قيمتها عن 0x20 قبل حساب FCS، لأن معدات الاتصال الوسيطة قد تدخلها. كانت قاعدة ضيقة خاصة باتجاه واحد، وليست إذناً بمحو أي تغيير.
  • عالج حشو الثمانيات وحشو البتات المشكلة نفسها بتمثيلين مختلفين. يثبت FCS الصحيح كشف الأخطاء على الإطار المستعاد، ولا يثبت الهوية أو المصادقة أو أن المسار المادي لم يتغير.

ما ظهر على السلك لم يكن كله من الإطار

لنفترض أن تسجيلاً تسلسلياً أظهر محرف تحكم لم يضعه الطرف المرسل في الإطار. قد يكون مودم أو برنامج تشغيل طرفية أو جهاز اتصال آخر قد أضافه. إدخاله في حساب FCS يجعل إطاراً سليماً يبدو فاسداً. وحذف كل بايت غير متوقع يتيح إخفاء فساد حقيقي في الحمولة.

اختار RFC 1662 استثناءً محدوداً. قبل حساب FCS تُزال الثمانيات المشار إليها في Async-Control-Character-Map المستقبلة، وتُعكس سلاسل Control Escape. وهكذا يكون موضوع الفحص إطار PPP الذي أعيد بناؤه وفق قواعد مشتركة، لا كل أثر مادي ظهر في أي نقطة من الطريق.

يمكن وصف ذلك تحريرياً بالتوحيد، لكن RFC لا يعرّف حقلاً بهذا الاسم. مصدر الانضباط هو قائمة التحويلات المغلقة وترتيبها.

حُسبت قيمة الفحص قبل إضافة هيئة المسار

يبدأ إطار HDLC-like وينتهي براية قيمتها 0x7e. وبين الرايتين تقع Address وControl وProtocol وInformation وPadding الاختياري ثم FCS. الشكل الافتراضي 16 بت، ويوجد شكل 32 بت. يغطي الحساب الحقول من Address إلى Padding، ولا يشمل الرايات أو FCS نفسه أو بتات البدء والتوقف أو إضافات الشفافية.

في وصلة تعتمد octet stuffing تكون 0x7d هي Control Escape. يجب على المرسل على الأقل حماية 0x7e و0x7d. الترتيب حاسم: يحسب FCS أولاً، ثم يفحص ما بين الرايتين. تتحول كل ثمانية مطلوب حمايتها إلى 0x7d تليها القيمة الأصلية بعد XOR مع 0x20. لذلك تُرسل 0x7e على هيئة 0x7d 0x5e، وتُرسل 0x7d على هيئة 0x7d 0x5d.

يعكس المستقبل العملية قبل الفحص: يزيل Control Escape ويطبق XOR مع 0x20 على الثمانية التالية. وإذا أتت الراية مباشرة بعد Escape يُجهض الإطار ولا يُنشأ بايت بيانات. يجوز نزع الهيئة المؤقتة لأنها محددة وقابلة للعكس، لا لأن للمستقبل حرية تأويل المحتوى.

كانت ACCM مطلباً لاتجاه واحد

تعارضت محارف ASCII للتحكم مع بعض المسارات غير المتزامنة. فقد يعترض التحكم البرمجي في التدفق XON عند 0x11 أو XOFF عند 0x13، وأحياناً من دون اعتبار لبت parity. مكّن PPP من تمرير هذه القيم بالهروب، ومن حذف محارف التحكم الدنيا المضبوطة بوصفها إضافات محتملة من الطريق.

احتفظ كل طرف غير متزامن بخريطتين: ACCM مستقبلة من 32 بت للقيم دون 0x20، وACCM مرسلة قد تبلغ 256 بت. توجد أربع خرائط عبر اتجاهي الوصلة، لا قائمة منع عالمية واحدة.

خيار ACCM في LCP من النوع 2 وطوله 6 ويحمل خريطة من أربع ثمانيات. البت المضبوط يلزم النظير بإبقاء محرف التحكم المقابل في صورة mapped عند الإرسال إلى طالب الخيار. أما البت الصفري فيعني أن ذلك غير واجب، ولا يمنع المرسل من الهروب. ويجوز للمرسل حماية قيم إضافية بسبب قيود محلية يعرفها في مساره.

يحدد المستقبل الحد الأدنى المطلوب لمساره الداخل، بينما يحتفظ المرسل بمساحة للاحتياط. وينبغي أن يقترح Configure-Nak اتحاد المجموعات المطلوبة حتى يمكن تجاهل المحارف التي يدخلها الطريق خطأ. تظل السلطة محلية ومقيدة بالاتجاه.

في الوصلة المتزامنة أضيف بت لا ثمانية هروب

لا ينسخ bit-synchronous framing طريقة 0x7d. بعد حساب FCS يضع المرسل صفراً بعد كل خمسة بتات متتالية قيمتها واحد، بما فيها السلاسل داخل FCS. ويحذف المستقبل هذا الصفر قبل حسابه. فلا يظهر نمط الراية مصادفة داخل الإطار.

تشترك الطريقتان في ترتيب واحد: تُضاف الشفافية بعد إنتاج قيمة الفحص وتُزال قبل التحقق منها، لكن صورة السلك مختلفة. يتولى المحول بين غير المتزامن والمتزامن ترجمة الحشو. ويلزم RFC 1662 التنفيذ المتزامن بتأكيد خيار ACCM من أجل توافق المحول، مع توضيح أن التأكيد لا يثبت أن الطرف المتزامن نفسه ينفذ octet mapping.

قبول الضبط قد يخدم مكوّناً وسيطاً، ولا يحدد وحده موضع التنفيذ.

إسقاط الإطار لم يكن دائماً خطأ FCS

يُسقط بصمت الإطار القصير جداً، أو الذي ينتهي بـControl Escape معلقة قبل راية الإغلاق، أو الذي يخالف octet framing، ولا يُحسب ذلك خطأ FCS. وفي نمط bit stuffing تكون السلسلة غير الصالحة التي تزيد على ستة بتات واحد حالة framing مماثلة.

لذلك قد تخفي مراقبة عداد FCS وحده العطل الحقيقي. الالتقاط بعد أن يكون برنامج التشغيل قد أزال الهروب لا يعرض الشيء نفسه الذي يعرضه التسجيل التسلسلي الخام. ويمكن لمحلل يستخدم ACCM أو نمط حشو أو عرض FCS خاطئ أن يصنع «مجموعاً سيئاً» لم يحسبه الطرف أصلاً.

يجب أن يتضمن الحد الأدنى لسجل الحادث الاتجاه، خرائط الإرسال والاستقبال، نمط الوصلة، شكل FCS، نقطة الالتقاط، مرحلة فك التمثيل، عدادات الإطارات غير الصالحة، والبايتات الخام والمستعادة.

لم يكن كثير الحدود إثباتاً للهوية

عرّف RFC 1570 بدائل Null و16 بت و32 بت بحسب الاتجاه والمرحلة. وأوصى RFC 1662 بالشكل ذي 32 بت عند استخدام NRZI لأنه يضعف خصائص الكشف في FCS ذي 16 بت. تلك اختيارات لكشف الخطأ، لا للمصادقة.

يحذر قسم الأمن في RFC 1662 بصورة منفصلة من أن طبقة الوصلة قد لا تعلم بتغير الاتصال المادي، وأن الإدخال أو انتحال هوية المتصل قد يكسر افتراضات ثقة أخرى. قد يحمل إطار قادم من امتداد مادي خاطئ FCS سليماً تماماً. يفحص كثير الحدود البتات، لا حق الطرف في الإرسال.

كانت مساهمة PPP التاريخية في ضيق الاستثناء. استطاع المسار تعديل هيئة النقل من دون إعادة تعريف الحمولة لأن ما يُستثنى محدد، واتجاهي، وقابل للعكس. تحويل القاعدة إلى سلطة عامة لحذف البايتات المزعجة يهدم الحد الذي أُنشئ FCS لحمايته.

المصادر