يوضح هذا المستند كيفية تفسير أكواد أسباب قطع الاتصال التي تم الإبلاغ عنها بواسطة أجهزة مودم تجميع قناة ISDN للمودم من Cisco Modem (MICA).
ملاحظة: تحتوي هذه الوثيقة على العديد من المصطلحات المحددة في معايير الاتحاد الدولي للاتصالات السلكية واللاسلكية مثل V.90 و V.44 و V.42bis و V.34. لمزيد من المعلومات حول هذه المصطلحات، يرجى الرجوع إلى معيار ITU-T المناسب. لم يتم شرح الشروط المحددة في معايير ITU-T في هذا المستند.
يجب أن يكون قراء هذا المستند على دراية بما يلي:
كلما تم مسح أو قطع اتصال مكالمة تستخدم أجزاء معينة من مجال MICA (DSPs)، تسجل MICA سبب قطع الاتصال. يمكنك إستخدام هذا السبب لتحديد ما إذا كان قطع الاتصال طبيعيا أم لا. وإن لم يكن الأمر كذلك، فيمكنك إستخدامه لتعقب مصادر الفشل المحتملة. يمكن قطع اتصال أجهزة المودم بسبب مجموعة متنوعة من العوامل مثل قطع اتصال العميل وأخطاء Telco وحالات قطع الاتصال في خادم الوصول إلى الشبكة (NAS). سبب قطع الاتصال النموذجي هو أن DTE (مودم العميل أو NAS) يريد إيقاف تشغيله في نهاية واحدة. يشير قطع الاتصال "العادي" هذا إلى أن قطع الاتصال لم يكن نتيجة أخطاء في المودم أو مستوى الإرسال. لمزيد من المعلومات حول تحديد ما إذا كان سبب قطع الاتصال طبيعيا أم لا، ارجع إلى نظرة عامة على جودة خط المودم العام و NAS.
يتم إستخدام أجهزة المودم MICA في خوادم Access التالية:
الموجّهات من السلسلة 3600 من Cisco
الطراز AS5200
الطراز AS5300
الطراز AS5800
تم إنشاء المعلومات المُقدمة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كنت تعمل في شبكة مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر قبل استخدامه.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.
أستخدم الأمر show modem log slot/port للعثور على الحالة الحالية لمودم MICA. في إخراج السجل هذا، تظهر أحدث الإدخالات قرب نهاية السجل. يتم عرض حالة مودم MICA الحالي في حدث (تغيير) حالة المودم الأخير. في إخراج المثال أدناه، تكون حالة المودم خاملة، كما هو موضح بواسطة حدث حالة المودم المختوم 00:00:28. ارجع إلى جدول حالات مودم MICA للحصول على مزيد من المعلومات حول حالات مودم MICA المحتملة.
maui-nas-02#show modem log 1/0 Modem 1/0 Events Log: 00:03:33:Startup event:MICA Hex modem (Managed) Modem firmware = 2.7.3.0 !--- This modem is using portware 2.7.3.0 00:03:33:RS232 event: noRTS, noDTR, CTS, noDCD ... ... !--- This output was removed for brevity. ... 00:00:28:Modem State event: State: Terminate 00:00:28:RS232 event: noRTS, DTR, CTS, noDCD 00:00:28:RS232 event: RTS, DTR, CTS, noDCD 00:00:28:Modem State event: State: Idle !--- The last modem state event !--- This indicates that the modem is in state Idle
عند إنهاء اتصال مودم، يبلغ NAS عن سببين لانقطاع الاتصال: أسباب DTE (IOS) وأسباب DCE (MICA). يمكن الإبلاغ عن أسباب قطع الاتصال هذه باستخدام ثلاث طرق أساسية:
سجلات مكالمات المودم: تشير هذه التقارير إلى أسباب انقطاع كل من برنامج IOS® ومودم MICA.
سجلات محاسبة AAA: هذا التقرير فقط سبب قطع اتصال برنامج IOS.
أوامر IOS: تقوم الأوامر مثل show modem operational-status وshow modem log فقط بالإبلاغ عن سبب انقطاع مودم MICA.
يتم عرض سبب قطع اتصال IOS والمودم لاتصال معين في سجل مكالمات المودم (MCR). يتم إرسال MCR إلى خادم syslog بواسطة NAS أثناء إنهاء كل مكالمة. تم إدخال سجلات مكالمات المودم في البرنامج Cisco IOS Software، الإصدار 11.3a و 12.0T ويتم تنشيطها (على NAS) باستخدام سجل مكالمات المودم للأمر. لمزيد من المعلومات حول تنفيذ سجلات مكالمات المودم، ارجع إلى المستند باستخدام Syslog و NTP وسجلات مكالمات المودم لعزل الأخطاء واستكشاف أخطائها وإصلاحها.
في سجل مكالمات المودم العينة الموضح أدناه، يكون سبب انقطاع IOS المشار إليه بواسطة disk(radius) هو Lost Carrier/Lost Carrier، بينما يكون سبب قطع اتصال المودم المشار إليه بواسطة disk(modem) هو:
A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received DISC frame -- normal LAPM termination
ارجع إلى أسباب قطع اتصال مودم Mica للجدول للحصول على مزيد من المعلومات حول تفسير سبب قطع اتصال المودم.
*May 31 18:11:09.558: %CALLRECORD-3-MICA_TERSE_CALL_REC: DS0 slot/contr/chan=2/0/18, slot/port=1/29, call_id=378, userid=cisco, ip=0.0.0.0, calling=5205554099, called=4085553932, std=V.90, prot=LAP-M, comp=V.42bis both, init-rx/tx b-rate=26400/41333, finl-rx/TX brate=28800/41333, rbs=0, d-pad=6.0 dB, retr=1, sq=4, snr=29, rx/TX chars=93501/94046, bad=5, rx/TX ec=1612/732, bad=0, time=337, finl-state=Steady, disc(radius)=Lost Carrier/Lost Carrier, disc(modem)=A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received DISC frame -- normal LAPM termination
كما يمكن إستخدام سجلات محاسبة AAA لتحديد سبب قطع اتصال IOS. في استعلام AAA SQL العينة أدناه، يمكننا رؤية سبب انقطاع اتصال نصف القطر:
SQL> select * from cs_accounting_log where blob_data like '%rad_dial%'; LOG_ID BLOB_ORDINAL BLOB_DATA ------------------------------------------------------------------------------- 172.22.87.3 rad_dial Async20 65004 stop server=danvers time=17:36:33 date=04/17/2000 task_id=40 timezone=CST service=ppp protocol=ip addr=172.22.83.12 disc-cause=4 disc-cause-ext=1021 pre-bytes-in=132 pre-bytes-out=139 pre-paks-in=5 pre-paks-out=7 bytes_i
يشير رمز قطع الاتصال (disk-cause=4)، في المثال أعلاه، إلى أن قطع الاتصال حدث بسبب انتهاء مهلة الخمول.
ملاحظة: لا تعرض سجلات محاسبة AAA سبب قطع اتصال MICA، وبالتالي لا يمكن إستخدام الجدول الوارد في هذا المستند لترجمة سبب قطع اتصال RADIUS.
لمزيد من المعلومات حول تنفيذ محاسبة AAA، ارجع إلى المستند الذي ينفذ محاسبة AAA المستندة إلى الخادم.
يمكن إستخدام أوامر IOS show modem operational-status slot/port وshow modem log slot/port لتحديد سبب انقطاع MICA.
يوضح إخراج هذا الأمر سبب فقدان الاتصال أو سبب عدم كون الاتصال الحالي كما تتوقعه. راجع أسباب قطع الاتصال أدناه للحصول على توضيحات حول أنواع الانفصال المختلفة.
as5300-2#show modem operational-status 1/1 Modem(1/1) Operational-Status: Parameter #0 Disconnect Reason Info: (0xDF03) Type (=6 ): TX (host to line) data flushing - OK Class (=31): Requested by host Reason (=3 ): DTR dropped ! --- This output was shortened for brevity.
يعرض show modem log slot/port أيضا سبب قطع الاتصال
maui-nas-02#show modem log 1/0 Modem 1/0 Events Log: 00:03:33:Startup event:MICA Hex modem (Managed) Modem firmware = 2.7.3.0 ... ... ! --- This output was removed for brevity. ... 00:00:26:End Connect event: Call Timer: 124 secs Disconnect Reason Info: (0x8220) Type (=4 ): Rx (line to host) data flushing - OK Class (=2 ): EC condition - locally detected Reason (=32): received DISC frame -- normal LAPM termination
ويتكون سبب الانقطاع من أربعة أرقام سداسية عشرية. يمكن إستخدام الأرقام السداسية العشرية الثلاثة منخفضة الترتيب لتحديد سبب قطع الاتصال. يشير الرقم السداسي العشري عالي الترتيب بشكل عام إلى نوع سبب قطع الاتصال أو الوقت الذي حدث فيه سبب قطع الاتصال. يتم وصف هذه الخيارات في سبب قطع الاتصال بالقسم: الأنواع. على سبيل المثال، إذا كان سبب قطع الاتصال هو 0xWXYZ، فيمكن ل 0xXYZ تحديد سبب قطع الاتصال بينما يشير 0xW إلى وقت حدوث سبب قطع الاتصال.
في الأمثلة الواردة أعلاه، يحدد 0xF03 و0x220 سبب انقطاع الاتصال بينما يشير 0xD و0x8 إلى وقت حدوث سبب قطع الاتصال. يتم توفير التعريفات الخاصة بأسباب قطع اتصال MICA في القسم أسباب قطع اتصال مودم MICA.
لمزيد من المعلومات حول عمليات مودم MICA، راجع التحقق من أداء المودم ووثائق عمليات إدارة المودم في دراسة الحالة Cisco AS5x00 لخدمات مودم IP الأساسية.
الحالة | الوصف |
---|---|
وضع الخمول (#0) | في هذه الحالة، جلسة عمل المودم غير نشطة حاليا. يتم إدخال حالة الخمول من حالة الإنهاء عند تلقي التحقق من DSP بأن جميع العمليات قد تم إيقاف تشغيلها. |
CALL_SETUP (#5) | وفي هذه الحالة، يكون معالج إشارة المودم مستعدا لاستقبال وتوليد T1 والتردد المتعدد (MF) والتردد المتعدد للطنين المزدوج (DTMF) و R1 و R2 وإشارات تقدم الاتصال. يبقى المودم في حالة CALL_SETUP حتى يستلم رسالة LINK_TERMINATE أو SOFTWARE_RESET أو INITIATE_LINK من المضيف. |
الاتصال (#10) | يتم إدخال حالة الاتصال من حالة CALL_SETUP(#5) فقط عند تلقي الأمر المضيف للبدء. في وضع "الرد"، بدأت جلسة عمل المودم نشاطا، ولكنها لم تبدأ بعد في إنتاج "نغمة الرد". في الوضع الأصلي، قامت جلسة عمل المودم ببدء النشاط، ولكنها لم تكتشف بعد "درجة ResponseBack". |
إرتباط (#15) | يتم إدخال حالة الارتباط من حالة الاتصال فقط عند اكتشاف نغمة الرد (المنشأ) أو بدء نغمة الرد (الإجابة). في وضع الرد، ترسل جلسة عمل المودم نغمة الرد إلى الخط. في الوضع الأصلي، كشفت جلسة عمل المودم الحد الأدنى (القابل للتكوين) لمقدار درجة AnswerBack المطلوب. وهذا يشير إلى وجود نظير بعيد. |
QC (#16) | يتم إدخال الاتصال السريع (QC) إما من حالة تبادل LINK أو V.8 مكرر إذا تم تمكين QC وعند تلقي تسلسل QCA (الوضع الأصلي) أو عند إرسال تسلسل QCA (وضع الرد). |
برنامج التدريب (رقم 20) | في هذه الحالة، تتفاوض جلسة عمل المودم على معيار التعديل المادي (كما تم تكوينه) المستخدم أثناء الارتباط. يتم إدخال حالة التدريب من حالة الارتباط فقط عند:
|
تفاوض EC (#25) | في هذه الحالة، تتفاوض جلسة عمل المودم على بروتوكول تصحيح الخطأ وضغط البيانات الذي سيتم إستخدامه أثناء الارتباط. عندما تكون الإعدادات مقبولة لكل من أجهزة المودم (التقاطع بين إمكانيات أجهزة المودم والتكوين)، يتم الوصول إلى تفاوض ناجح. إذا كان التقاطع فارغا، فإن المودم إما أنه ينقطع الاتصال بجلسة عمل غير متصلة بخطأ أو يقوم بتشغيلها. يتم إدخال الحالة المتفاوضة ل EC_Negotiation من حالة التدريب بعد إتمام مزامنة التعديل المادي بنجاح. |
Steady_State (#30) | في هذه الحالة، يمكن لجلسة عمل المودم تمرير البيانات على الارتباط. الدولة المستقرة يتم دخولها من الدولة المتفاوضة الواقعة ضمن المجموعة الأوروبية:
|
Steady_State_Retraining (#35) | في هذه الحالة، يتم حاليا إعادة تدريب جلسة عمل المودم. تكون حالة إعادة التدريب الثابت من الحالة المستقرة أو من الحالة المستقرة_الحالة_التي تتحول فيها السرعة هي:
|
Steady_state_shiftSpeed (#40) | في هذه الحالة، تحول جلسة عمل المودم السرعة حاليا. وعندها تدخل حالة الثبات_الحالة_المحول للسرعة من حالة الثبات:
|
Steady_State_Escape (#45) | في هذه الحالة، لا يزال المودم متصلا مع النظير البعيد، ولكن واجهة المضيف في وضع الأمر AT. يتم إدخال هذه الحالة فقط عند تلقي تسلسل هروب صالح من Hayes. في وضع الفاكس، تعني هذه الحالة أن محرك T30 يقبل أوامر AT من المضيف. راجع حالة (#30) الثابت للحصول على معلومات حول مكالمة فاكس. |
إنهاء (#50) | في هذه الحالة، تحاول جلسة عمل المودم مسح بيانات المستخدم ومسح معالج الإشارة الرقمية (DSP). في برنامج_reset، لا يوجد تدفق منظم، كما تتم إعادة تعيين DSP. يتم إدخال حالة الإنهاء من أي ولاية:
|
قيد الانتظار ( #55 ) | جلسة عمل المودم قيد الانتظار، ولا تمرر أي بيانات على الارتباط. يتم إدخال حالة "قيد الانتظار" من الحالة الثابتة عند تلقي رسالة طلب المودم قيد الانتظار (MoH) (MHReq). إذا تم تمكين المودم قيد الانتظار (السجل S62)، يرسل المودم تسلسل "الإقرار بالإبقاء على الانتظار" (MHack) لمنح الطلب وبث الدرجة الثانية من الإجابة (ANSam) عند اكتشاف الصمت أو RT. إذا تم اكتشاف إشارة قائمة الاتصال (CM) (ل V.8) أو تسلسل QCA الخاص بالاتصال السريع (QC - التسجيل S63) في حالة الانتظار، فيجب على المودم الخروج من حالة الانتظار والاستجابة إلى تسلسل البدء الذي يتبع توصيات V.8 أو QC (Register S63) على التوالي. إذا لم يتم اكتشاف أي تسلسل بدء بعد تحديد قيمة مهلة الانتظار، يجب على المودم الخروج من حالة الانتظار وفصل الاتصال. إذا كان المودم قيد الانتظار معطلا، يرسل المودم ذاكرة MHnack. إذا تم اكتشاف MHcda بعد إرسال MHnack، يجب قطع اتصال المودم. إذا تم اكتشاف MHfrr بعد إرسال MHnack، يرسل المودم طنين الإجابة الخلفية ويستعد لاكتشاف تسلسلات CM (V.8) أو QCA (QC - Register S63) من المودم البعيد. لمزيد من المعلومات حول المودم قيد الانتظار، ارجع إلى مواصفات ITU-T V.92 . ملاحظة: كانت MICA State #55 في السابق الدولة الصوتية، التي تمت إزالتها الآن من الإصدارات 2.9.1.0 وما فوقها. |
V.8bis Exchange (#71) | يتم إدخال هذه الحالة من حالة الاتصال فقط عند اكتشاف CRe (الوضع الأصلي) أو بدء CRe(وضع الرد). وضع الإجابة: تقوم جلسة عمل المودم بإرسال طلب إمكانية الرد التلقائي (CRe) إلى السطر. الوضع الأصلي: كشفت جلسة عمل المودم عن إمكانية الرد التلقائي على الطلب (CRe). وهذا يشير إلى وجود نظير بعيد. |
النطاق (#72) | يتم إدخال المدى من حالة LINK أو QC (Register S63) عند بدء تقدير تأخير جولة الذهاب (RTDEd). وتنطبق هذه الحالة فقط على المعايير V.32 وما فوق. |
نطاق قصير(#73) | يتم إدخال المدى القصير من QC (register S63) عند بدء تشغيل المودم الرقمي-تقدير تأخير الجولة (RTDEd) |
قطار فائق الدقة (#74) | يتم إدخال قطار الدقة الفائقة (HD) (التدريب على الإرسال أحادي الإتجاه) إما من المدى أو من المدى القصير عند بدء تدريب مرشح التكيف. وينطبق هذا على V.22bis وما فوق. |
Steady_STATE_PIAFS_RESYNC(#80) | يشير إدخال STEADY_STATE_PIAFS_RESYNC إلى فقدان مزامنة مكالمة Handyphone Personal Internet Forum (PIAFS) وأنها تقوم بإعادة المزامنة. |
Steady_STATE_PIAFS_SPEEDSHIFT(#85) | يشير إدخال STEADY_STATE_PIAFS_SPEEDSHIFT إلى أن إستدعاء PIAFS يتفاوض على تغيير نوبة السرعة. هذه دولة انتقالية وقتية. ميكا لن تبقى أبدا في هذه الحالة. إذا نتج عن إعادة التزامن تحولا سريعا، فإن MICA تنتقل إلى هذه الحالة من STEADY_STATE_PIAFS_RESYNC، ثم تنتقل إلى STABLE_STATE. إذا لم ينتج عن إعادة التزامن تحولا في السرعة، فسيتم نقل STEADY_STATE_PIAFS_RESYNC مباشرة إلى STEADY_STATE عند الاكتمال. |
يتكون سبب انقطاع مودم MICA من أربعة أرقام سداسية عشرية. تعرف الأرقام السداسية العشرية المنخفضة الترتيب بشكل فريد سبب انقطاع الاتصال. يشير الرقم السداسي العشري عالي الترتيب إلى نوع سبب قطع الاتصال أو الوقت الذي حدث فيه سبب قطع الاتصال. في المثال أعلاه، عندما يكون رمز قطع الاتصال سداسي عشر 0xDF03، يحدد 0xF03 سبب قطع الاتصال بينما يشير 0xD إلى وقت حدوث سبب قطع الاتصال (سبب قطع الاتصال: الأنواع).
لا تتضمن أسباب قطع الاتصال الموضحة أدناه نوع قطع الاتصال. لذلك، من سبب عدم الاتصال لديك، اخلع الرقم السداسي العشري الأيسر وقارن الأرقام المتبقية مع الخيارات أدناه. من المثال أعلاه، ابحث عن 0xF03 في القسم أدناه.
ملاحظة: في هذا المستند، يمثل المودم المضيف مودم MICA على خادم الوصول من Cisco، بينما يمثل مودم العميل مودم الجهاز البعيد (على سبيل المثال، مودم كمبيوتر عميل).
نوع قطع الاتصال | قطع اتصال كود السبب | الوصف |
---|---|---|
- | 0 | لم يحدث أي قطع اتصال حتى الآن. ترى هذا الرمز إذا تم الاستعلام عن سبب قطع الاتصال مباشرة بعد تحميل Portware أو أثناء مكالمة، قبل الحالة الثابتة. |
أسباب قطع الاتصال العامة (الفئة 0) | ||
2 | 0x001 | قام Cisco IOS بإنهاء المكالمة بشكل مفاجئ لسبب ما - على سبيل المثال، لأن الطبقة 1 سقطت على الفسحة بين دعامتين فيزيائيتين تحتويان على المكالمة. |
2 | 0x002 | إنهاء طبقة تصحيح الأخطاء (EC). |
2 | 0x003 | تلقت مهمة فك ضغط بروتوكول شبكة Microcom رقم 5 (MNP5) رمز مميز غير قانوني في تدفق البيانات. يحدث سبب قطع الاتصال هذا أثناء وضع البيانات (0x3003). قد يكون هناك خطأ منطقي في تطبيق المودم أو الشريك ل de/compression أو تصحيح الخطأ. (هناك أيضا احتمال حدوث خطأ متكرر في السطر أو في ذاكرة ذاكرة RAM.) |
2,4,6 | 0x004 | تلقت مهمة الضغط V.42bis أو V.44 رمز مميز غير قانوني في تدفق البيانات. قد يحدث سبب قطع الاتصال هذا أثناء وضع البيانات (0x4004). قد يكون هناك خطأ منطقي في تطبيق المودم أو الشريك ل de/compression أو تصحيح الخطأ. (هناك أيضا احتمال حدوث خطأ متكرر في السطر أو في ذاكرة ذاكرة RAM.) بالنسبة ل V.44، يتم استكمال هذا الرمز بالفهرس 119 لحقل معلومات الارتباط التشخيصي (حقل معلومات مكون من ثمانية بايت يتم إستخدامه كأداة لتصحيح الأخطاء). |
2 | 0x005 | خطأ في برنامج MICA. رمز الخطأ لسبب قطع الاتصال هذا هو 0x4005. حدث خطأ في برنامج MICA يشير إلى متغير حالة مساعد معالج سيئ. |
6 | 0x006 | تم اكتشاف أمر ATH بواسطة المودم المحلي. يحدث سبب قطع الاتصال هذا أثناء وضع البيانات (0xC006 و 0xE006). تم اكتشاف الأمر ATH (Hangup) بواسطة المودم المحلي (MICA). على سبيل المثال، أثناء اتصال من IOS، بعد اتصال المكالمة، قامت واجهة IOS DTE بمسح المكالمة عن طريق إرسال أمر ATH داخل النطاق. |
3 | 0x007 | تم إجهاض الأمر AT . تم إجهاض الأمر AT dial بواسطة الأمر any key abort. على سبيل المثال، يقوم المودم المضيف بإنشاء مكالمة. أثناء إنشاء الاتصال، وقبل الحالة الثابتة، سيؤدي الضغط على أي مفتاح إلى إجهاض أمر طلب AT. |
3 | 0x008 | استغرقت المكالمة وقتا طويلا لإكمال الاتصال. لاحظ أن مؤقت S7 (انتظار الناقل بعد الطلب) انتهت صلاحية قطع الاتصال هذا. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (0x6008). استغرق المودم المضيف وقتا طويلا جدا لإنشاء اتصال بسبب إعادة التدريب. والأسباب هي: صعوبة إختيار (التفاوض) معيار من الطبقة الأولى (على سبيل المثال، إجهاض المكالمة قبل العودة باستخدام سبب قطع الاتصال 0x6102)، أو مزيج من إنشاء من الطبقة الأولى والطبقة الثانية يستغرق وقتا طويلا. على سبيل المثال، تستغرق مفاوضات تصحيح الأخطاء وقتا طويلا فوق إعادة التدريب أو بسبب أخطاء البت التي تم إدخالها عندما يحاول مودم العميل الاتصال بمعدل مذهل (يحاول مستقبل مودم العميل الاتصال بمعدل لا يمكنه تحمله). هذا النوع من عدد قطع الاتصال مقابل CSR. يمكن أن يحدث هذا الانقطاع أيضا إذا لم يسمع مودم الإجابة نغمة من القناة (على سبيل المثال، لم يكن المنشئ مودم). |
2 | 0x009 | تم إعادة تعيين DSP (الأمر، الداخلي أو التلقائي). رمز الخطأ لسبب قطع الاتصال هذا هو 0x4009. تم إعادة تعيين DSP داخل المودم المضيف بواسطة معالج التحكم (CP) أو معالج الإشارة (SP). سيقوم "cp" بإعادة تعيين DSP إذا لم يتم الاعتراف برسائل البريد من CP إلى SP. سيقوم SP بإعادة تعيين نفسه إذا حصل على خطأ عدم تناسق داخلي. |
4,6 | 0x00a | إستلام كلمة كود STEPUP غير قانونية. يحدد إستلام كلمة رمز STEPUP عندما يتسبب في تجاوز قيمة C2 (حجم كلمة التعليمات البرمجية الحالي) N1 (الحد الأقصى لحجم كلمة التعليمات البرمجية: تم التفاوض عليه) وتكون صالحة ل V.44 و V.42bis فقط. |
4,6 | 0x00b | إستلام كلمة كود V.42bis غير قانونية. يحدد إستلام كلمة التعليمات البرمجية، في أي وقت، تساوي C1 (مدخل القاموس الفارغ التالي) وصالحة ل V.42bis. (يعد تلقي كلمة رمز = C1 غير قانوني في V.42bis، ولكنه قانوني في V.44). |
4,6 | 0x00c | إستلام رمز مميز غير قانوني (كبير جدا) في V.44 أو V.42bis. وهذا يعني أن حجم كلمة التعليمات البرمجية الواردة V.42bis أو V.44 قد تجاوز الحد الأقصى الذي تم التفاوض عليه. يحدد إستلام كلمة التعليمات البرمجية، في أي وقت، أكبر من C1 (مدخل القاموس الفارغ التالي) وصالحة ل V.44 و V.42bis. |
4,6 | 0x00d | إستلام رمز أمر محجوز V.44 أو V.42bis. تحديد إيصال رمز أمر محجوز وصالح ل V.44 و V.42bis. |
4,6 | 0x00e | تلقى V.42bis أو V.44 كلمة تعليمات برمجية أكبر من إدخال القاموس الفارغ التالي. إستلام حرف V.44 غير قانوني. وهذا يشير إلى إستلام رمز تحكم STEPUP الذي من شأنه أن يتسبب في تجاوز قيمة C5 (الحجم الترتيبي) لثمانية. هذا صالح ل V.44 فقط. |
4,6 | 0x00f | قاموس V.44 RX كامل. يحدد إستلام كلمة التعليمات البرمجية التي ليست إعادة تعيين قاموس عندما تكون شجرة عقدة Rx ممتلئة. صالح ل V.44 فقط. |
4,6 | 0x010 | محفوظات V.44 RX ممتلئة. يحدد إستلام كلمة التعليمات البرمجية التي ليست إعادة تعيين قاموس عندما يكون محفوظات Rx ممتلئة. صالح ل V.44 فقط. |
4,6 | 0x011 | تجاوز حجم سلسلة V.44/V.42bis غير القانوني ل Rx. يحدد إستلام كلمة التعليمات البرمجية التي تتسبب في تجاوز الحد الأقصى لحجم السلسلة التي تم التفاوض عليها. وهو صالح للإصدار V.44 والإصدار V.42bis. |
4,6 | 0x012 | حدث خطأ في التفاوض V.44 يحدد حدوث خطأ في التفاوض V.44. بالنسبة ل V.44، يتم استكمال هذا الرمز بالمؤشر 119 حقل معلومات الارتباط التشخيصي. فهرس حقل معلومات الارتباط التشخيصي هو حقل معلومات مكون من ثمانية بايت يتم إستخدامه كأداة لتصحيح الأخطاء. |
4,6 | 0x013 | حدث خطأ ضغط V.44 يحدد حدوث خطأ ضغط V.44. بالنسبة ل V.44، يتم استكمال هذا الرمز بالمؤشر 119 حقل معلومات الارتباط التشخيصي. فهرس حقل معلومات الارتباط التشخيصي هو حقل معلومات مكون من ثمانية بايت يتم إستخدامه كأداة لتصحيح الأخطاء. |
الشروط التي تم الإبلاغ عنها بواسطة DSP (الفئة 1) | ||
0x1xx | شروط DSP التي تم الإبلاغ عنها من قبل SPE | |
3,4,5 | 0x100 | فقد DSP إشارة الناقل. أي، كشف MICA عن إسقاط حامل مودم عميل. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمات ووضع البيانات (وذلك 0x6100 و 0x8100 و 0xA100). توقف MICA DSP عن سماع صوت الناقل لفترة تزيد عن القيمة المحددة في السجل S10 (تأخير الإيقاف بعد فقدان الناقل). وهذا يمكن ان يعني ان مسار الحديث ذهب بعيدا أو ان الزبون توقف عن الارسال. وإذا كان بروتوكول الطبقة الثانية (V.42 و/أو V.42bis) ساري المفعول، فسيكون من غير الطبيعي أن نرى مثل هذا الفصل. يحدث سبب قطع الاتصال هذا أحيانا أثناء تفاوض EC (قبل وضع البيانات). أي أنه تم التفاوض بنجاح على الطبقة الأولى (مما أدى إلى اكتشاف إشارة الناقل) ويحدث الانفصال أثناء محاولة إنشاء بروتوكول الطبقة الثانية (V.42 و/أو V.42bis). الأسباب الشائعة هي قيام المستخدمين بإجهاض المكالمة قبل إجراء الاتصال. الطلب العرضي، وبدء التشغيل التي تم إجهاضها، وتوقيت تطبيقات العميل بسبب قضاء وقت طويل جدا في الاتصال (على سبيل المثال، عمليات إعادة التوجيه المتعددة أثناء تفاوض الطبقة الأولى). يحتسب هذا النوع من الفشل في مقابل CSR. كما يمكن أن تحدث حالة فقد الناقل أثناء وضع البيانات العادي عندما يقوم العميل بإسقاط الناقل بشكل مفاجئ. يتمثل السبب المشترك في عدم التفاوض بشأن قطع الاتصال أو عدم الاتصال بشكل قذر من جانب مودم العميل (أي أن مودم العميل يقوم فقط بإسقاط إشارة الناقل). ويمكن أن يحدث ذلك إذا تم إسقاط الارتباط بشكل مفاجئ (أي خطأ في الشبكة)، ويتم إيقاف تشغيل طاقة مودم العميل لقطع الاتصال. ويمكن أن يحدث ذلك أيضا مع أجهزة مودم العميل الأقل تكلفة التي لا تنفذ بروتوكولات مسح الطبقة I و/أو الطبقة II على إسقاط DTR. بالنسبة لعدد كبير من أجهزة مودم العميل، يعتبر هذا الأمر قطع اتصال عادي. عندما يقوم مودم العميل بفصل قذر، توجد حالة عرقية بين 0xA103 و 0xA100 و 0xDF06. إذا اكتشف DSP داخل مودم المضيف خسارة ناقل، فإن 0xA100 يربح ويشار إليه على أنه سبب قطع الاتصال. إذا لم يكتشف مزود الخدمة المعتمد من Dell (المعروف إختصارا باسم DSP) أي خسارة في الناقل ويعيد تدريبه حتى يصل إلى حد السجل S40، فيفوز عندها 0xA103. إذا اكتشفت الشبكة أنه قد تم قطع اتصال المكالمة وقامت بإشارة الموجه إلى قطع الاتصال، فستكون نتيجة ذلك فوز 0xDF06. لا يحتسب سبب قطع الاتصال هذا مقابل CSR عندما يكون مودم المضيف في وضع البيانات. |
3 | 0x101 | يحدث ذلك عندما يكون معالج الإشارة (SP) في مرحلة اكتشاف الدرجة الخلفية للإجابة (ABT) عند حدوث فشل الاستدعاء. |
3 | 0x102 | فشل الاتصال أثناء تدريب المودم بسبب تعديل غير متوافق أو خط سيئ. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (0x6102). وقد يكون هذا مؤشرا على محاولات التفاوض على تعديل غير مدعوم مثل تعديل ملكية قديمة لشركة Rockwell (K56Plus، V.FC، وما إلى ذلك). ومن الأسباب الأخرى المحتملة حالات فشل DSP في التدريب بسبب تلف الخط الشديد، والأضواء المندفعة، والتدريب المتقطع، وبارامترات التعديل غير المتوافقة، وربما عدم القدرة على تحديد معيار من الطبقة الأولى بشكل صحيح. يحتسب هذا النوع من قطع الاتصال مقابل CSR. |
4,5 | 0x103 | عدد كبير جدا من عمليات إعادة التدريب المتتالية أو نوبات السرعة. يتم تحديد حد إعادة التدريب مع التسجيل S40. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمات ووضع البيانات (0x6103، 0x8103، و 0xA103). أثناء التقدم الذي تم إجراؤه في المكالمة، حدث عدد كبير للغاية من عمليات إعادة التوجيه التي جعلت المكالمة غير فعالة نظرا لأن معدل البيانات سيكون ضعيفا للغاية لدرجة أنه غير ذي نفع. تتمثل الشروط المحتملة في الحالات التي لا يكمل فيها مودم العميل بروتوكول التصفية (على سبيل المثال، قام Telco بإلغاء المكالمة في منتصف الاتصال) وتحاول MICA إسترداد المكالمة من خلال إصدار عمليات إعادة التوجيه. بمجرد الوصول إلى حد إعادة التدريب (يمكن تغيير حد إعادة التدريب باستخدام سجل S40)، تقوم MICA بإسقاط المكالمة والإبلاغ عن سبب قطع الاتصال هذا. في بعض الظروف (Channelized T1/E1) يمكن إعتبار هذا النوع من قطع الاتصال كقطع اتصال عادي ثابت بالحالة. وبدلا من ذلك، قد يكون هذا ببساطة نتيجة قطع اتصال قذر بسبب أخطاء خط محتملة لا يمكن ل MICA التعافي منها. وبالتالي، لا يحتسب هذا النوع من قطع الاتصال مع CSR لأن الاستدعاء تم إنشاؤه بالفعل. كما يمكن أن يحدث سبب قطع الاتصال هذا أثناء تفاوض EC عندما يكون مودم العميل عدوانيا بشكل مفرط مع معدل الاتصال الأولي ولا يمكنه الحفاظ على المكالمة (كما هو مودم عميل USRotics القديم). يحتسب هذا النوع من قطع الاتصال ضد CSR. عندما يقوم مودم العميل بفصل قذر، توجد حالة عرقية بين 0xA103 و 0xA100 و 0xDF06. إذا اكتشف معالج الإشارة الرقمي (DSP) داخل مودم المضيف وجود خسارة في حامل، فإن 0xA100 تكون هي الفائز ويشار إليها على أنها سبب قطع الاتصال. إذا لم يكتشف مزود الخدمة المعتمد من Dell (المعروف إختصارا باسم DSP) أي خسارة في الناقل ويعيد تدريبه حتى يصل إلى حد التسجيل S40، فيفوز 0xA103. إذا اكتشفت الشبكة أنه قد تم قطع اتصال المكالمة وقامت بإشارة الموجه إلى قطع الاتصال، فستكون نتيجة ذلك فوز 0xDF06. لا يحتسب سبب قطع الاتصال هذا مقابل CSR عندما يكون مودم المضيف في وضع البيانات. |
3 | 0x104 | مشكلة في الكشف عن نهاية درجة لون الإجابة (ABT). فشل التفاوض أو الضوضاء المفرطة أثناء التدريب على الإصدار 34. تقوم أجهزة المودم المضيفة بالإجابة وإرسال نغمة الإجابات الاحتياطية بمعدل 2100 هرتز مع عمليات عكس الطور، ولكنها تواجه ضوضاء مفرطة أثناء تسلسل التدريب. ابحث عن الأخطاء في المسار من مودم الاتصال إلى مودم الرد التلقائي في أي من الاتجاهين أو كليهما. يحدث سلوك مماثل عندما يكون هناك زمن وصول في شبكة الهاتف المحولة العامة (PSTN) للطلب الهاتفي الذي يتجاوز ثانية واحدة ويتسبب في عدم قدرة أجهزة المودم على تدريب أجهزة إلغاء الصدى. الأسباب الأخرى المحتملة هي:
|
3 | 0x105 | تم إكمال عملية SS7/COT (إختبار الاستمرارية) بنجاح يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (0x6105). اكتملت عملية SS7/COT (إختبار الاستمرارية) بنجاح. |
3 | 0x106 | فشلت عملية SS7/COT (إختبار الاستمرارية): مهلة T8/T24 في انتظار تشغيل طنين. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (أي 0x6106). فشلت عملية SS7/COT (إختبار الاستمرارية) بسبب انتهاء مهلة مؤقت T8/T24 أثناء انتظار تشغيل طنين. |
3 | 0x107 | فشلت عملية SS7/COT (إختبار الاستمرارية): مهلة T8/T24 في انتظار إيقاف طنين. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (0x6107). فشلت عملية SS7/COT بسبب انتهاء مهلة مؤقت T8/T24 أثناء انتظار إيقاف النبرة. |
4 | 0x108 | مسح المودم قيد الانتظار (Moh) بواسطة MICA. تم تلقي طلب مسح "المودم قيد الانتظار" من مودم العميل. V.92 يحدد أن سبب إلغاء التأمين يمكن أن يكون:
|
4 | 0x109 | تم الوصول إلى قيمة مهلة المودم قيد الانتظار (MOH). |
شروط المفوضية الأوروبية المحلية (الفئة 2) | ||
0x2xx | شروط المفوضية الأوروبية المحلية | |
3 | 0x201 | لم يتم تلقي إطار LR (طلب الارتباط) أبدا أثناء التفاوض. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (أي 0x6201). هذا يعني أن المودم المضيف لم يستلم أبدا إطار LR أثناء التفاوض على تصحيح الخطأ. قد لا يدعم مودم النظير بروتوكول MNP في V.42. |
3 | 0x202 | تم تلقي إطار LR مع معلمة غير صحيحة (PARAM1). يحتوي إطار طلب إرتباط MNP (LR) المستلم على PARAM1 غير صحيح أو غير متوقع. أحلت ل كثير معلومة على PARAM1 ال V.42 مواصفة. |
3 | 0x203 | تم تلقي إطار LR غير متوافق (طلب الارتباط). يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (0x6203). إطار MNP LR المتلقى غير متوافق مع إعدادات مودم المضيف ل EC. |
4,5 | 0x204 | عدد كبير جدا من عمليات إعادة الإرسال المتتالية. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمات ووضع البيانات (0x8204، 0xA204 و 0x6204). قد يتسبب سبب قطع الاتصال هذا في حدوث ضوضاء على الخط. على سبيل المثال، يقوم المودم المضيف بإرسال البيانات إلى مودم العميل، ولكن الضوضاء على الخط تتسبب في إستلام البيانات بشكل غير صحيح (أو لا يتم إستلامها على الإطلاق) من جانب العميل. فالضوضاء المفرطة يمكن ان تؤدي إلى اعادة نقل مفرطة. كما يمكن قطع اتصال مودم العميل دون أن يدرك مودم MICA ذلك. وبالتالي، يرسل المودم المضيف باستمرار، دون معرفة أن مودم العميل لم يعد موجودا. وفي بعض الأحيان، عندما يتصل الاستدعاء ببروتوكول ضغط خطأ (EC) (إجراء الوصول إلى الارتباط لأجهزة المودم (LAPM) أو بروتوكول شبكات Microcom (MNP))، يعجز MICA عن إرسال إطار إلى مودم العميل. يفشل المودم العميل في التعرف على الإرسال الأولي MICA، ثم يفشل في الاستجابة لاستطلاع حد إعادة الإرسال (تصحيح الخطأ) S19 (الافتراضي هو 12)، لذلك تقوم MICA بقطع الاتصال. قد يكون أحد الأسباب أن الناقل في مسار الإرسال قد انخفض بشكل كبير بينما فشل العميل في الانتقال. قد يكون سبب آخر مشكلة في محرك EC الخاص بالعميل (كما يحدث على نظام WinModem إذا توقف Windows عن الاستجابة). |
6,7 | 0x205 | مهلة عدم النشاط، تم إرسال قطع اتصال إرتباط MNP (LD). يحدث سبب قطع الاتصال هذا أثناء وضع البيانات (0xC205 و 0xE205). يرسل المودم المضيف مودم العميل إطار LD يشير إلى حدوث مهلة عدم نشاط. |
4,5 | 0x206 | خطأ في بروتوكول EC. يحدث سبب قطع الاتصال هذا أثناء وضع البيانات (0x8206 و 0xA206). هذا خطأ بروتوكول التقاط الكل عام. وهو يشير إلى حدوث خطأ في بروتوكول LAPM أو MNP EC. |
3 | 0x210 | لا يتوفر بروتوكول إحتياطي ل EC. يحدث سبب قطع الاتصال هذا في إعداد المكالمة (0x6210). لم ينجح تفاوض تصحيح الخطأ. يتم إنهاء الاستدعاء لعدم توفر بروتوكول تصحيح إحتياطي للتصحيح. يحدد S-register S25 (النسخ الاحتياطي لبروتوكول الارتباط) بروتوكول النسخ الاحتياطي المتاح. الخيارات هي الإطارات غير المتزامنة، الإطارات المتزامنة، أو قطع الاتصال (hangup). |
3 | 0x211 | لم يتم تلقي إطار معرف Xchange (XID) أثناء التفاوض. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمة (0x6211). هذا يعني أن المودم المضيف لم يستلم أبدا إطار XID أثناء التفاوض على تصحيح الخطأ. قد لا يدعم مودم العميل LAPM داخل V.42. |
3 | 0x212 | إطار XID المستلم غير متوافق مع الإعدادات المحلية. يحدث سبب قطع الاتصال هذا في إعداد المكالمة (0x6212). إطار XID المستلم غير متوافق مع إعدادات مودم المضيف. على سبيل المثال، قد يشير مودم العميل إلى MNP5، في حين يشير المودم المضيف إلى V.42 و V.42bis فقط. |
3,4,5 | 0x220 | إطار قطع الاتصال المتلقى (القرص). هذا هو قطع LAP-M العادي. يحدث سبب قطع الاتصال هذا أثناء إعداد المكالمات ووضع البيانات (0x 6220، 0x8220، و 0xA220). تم إنهاء المكالمة بشكل طبيعي بمسح مناسب من جانب العميل. (بمعنى أنه تم إرسال حزمة فصل V.42 من مودم العميل إلى مودم NAS.). قام مودم العميل بإسقاط DTR والتفاوض بشكل نظيف على بروتوكول مسح. |
3,4,5 | 0x221 | إطار DM المستلم. من المحتمل أن النظير لا يتصل. يحدث سبب قطع الاتصال هذا في إعداد المكالمات ووضع البيانات (0x6221، 0x8221، و 0xA221). يشير مودم العميل إلى أنه لا يتصل. أثناء إعداد المكالمة، يشير هذا السبب إلى أن مودم العميل قد تخلى عن التفاوض على تصحيح الخطأ. |
4,5 | 0x222 | تم تلقي رقم تسلسل غير صحيح. يحدث سبب قطع الاتصال هذا في وضع البيانات (0x8222 و 0xA222). تلقى المودم المضيف إطار تصحيح خطأ LAPM أو MNP مع رقم تسلسل غير صحيح أو رقم إقرار. يتم إرسال إطار LD أو رفض الإطار (FRMR) إلى مودم العميل يشير إلى أن مودم المضيف لا يتصل. |
4,5 | 0x223 | تم إستلام إطار SABME في حالة ثابتة. يحدث سبب قطع الاتصال هذا في وضع البيانات (0x8223 و 0xA223). يتم تفسير هذا على أنه خطأ بروتوكول تصحيح خطأ LAPM في حالة ثابتة. هذا يعني أن مودم العميل قد تم إعادة تعيينه بسبب تلقي رفض الإطارات (FRMR). |
4,5 | 0x224 | تم تلقي إطار XID الخاص ب MNP في حالة ثابتة. يحدث سبب قطع الاتصال هذا في وضع البيانات (0x8224 و 0xA224). يتم تفسير هذا على أنه خطأ بروتوكول تصحيح خطأ LAPM في حالة ثابتة. هذا يعني أن مودم العميل قد تم إعادة تعيينه بسبب تلقي رفض الإطارات (FRMR). |
4,5 | 0x225 | تم تلقي إطار MNP LR أثناء وجوده في حالة مستقرة. يحدث سبب قطع الاتصال هذا في وضع البيانات (0x8225 و 0xA225). يتم تفسير هذا على أنه خطأ بروتوكول تصحيح خطأ MNP في حالة ثابتة. وهذا يعني أن مودم العميل قد تم إعادة تعيينه. |
الشروط الخاصة ببروتوكول PIAFS (الفئة 2، تابع) | ||
3,4 | 0x230 | الرسالة المستلمة أقصر من الحد الأدنى للطول المحدد لنوع الرسالة هذا. |
3,4 | 0x231 | تم إستلام نوع إطار PIAFS غير معروف أو غير منفذ. وهذا يشمل FI (نوع الإطار الرئيسي) وفئة التفاوض أو المزامنة أو التحكم (النوع الفرعي). |
3,4 | 0x232 | معرف إطار التحكم في PIAFS (CFI) غير معروف. تم تلقي إطار تحكم بمعرف غير معروف أو غير منفذ لفئته. لاحظ أنه لا يتم تنفيذ الإطارات المستمرة وإطارات المستخدم، وأنه لا توجد إطارات إعلام معروفة. |
3,4 | 0x233 | فشل تفاوض اتصال PIAFS. بعد المزامنة الأولية، يتم تبادل إطارات Req/ACK لمعلمات الاتصال. إما أن المعلمات غير مقبولة، أو أن البادئ كشف عن إستجابة NAK (إعلام سالب). ملاحظة: لا يمكن أن تعمل وزارة الزراعة والصناعة إلا كعميل/بادئ لأغراض الاختبار |
3,4 | 0x234 | فشل تفاوض ARQ ل PIAFS. بعد إعادة التزامن، يتم تبادل إطارات طلب ARQ (REQ)/الإقرار (ACK). إما أن المعلمات غير مقبولة، أو أن البادئ اكتشف إستجابة Nak. ملاحظة: لا يمكن أن تعمل وزارة الزراعة والصناعة إلا كعميل/بادئ لأغراض الاختبار |
3,4 | 0x235 | تم الكشف عن مشاكل بروتوكول نقل التحكم في PIAFS. تلقى البادئ ACK/NAK/RSP لا يتطابق المعرف والفئة والتسلسل مع REQ/NTF الأصلي. ملاحظة: لا يمكن أن تعمل وزارة الزراعة والصناعة إلا كزبون أو بادئ لأغراض الاختبار |
3,4 | 0x236 | لم يعد سبب الانفصال هذا يشير إلى إستلام إطار طلب DataLinkRelease. وهو يشير الآن إلى قطع الاتصال بدون سبب قطع الاتصال الذي تم إنشاؤه مسبقا. هذا يعني أن MICA تقوم بفصل مكالمة، لكنها تجد أنه لم يتم نشر أي سبب. |
3,4 | 0x237 | انتهت صلاحية مؤقت انتظار انتظار مزامنة PIAFS (T001). يبدأ هذا المؤقت عند إرسال إطار طلب مزامنة، ويتوقف عند الكشف عن إطار إستقبال مزامنة. سيحدث هذا خطأ فقط عندما ال MICA ميناء يعمل كزبون أو بادئ، أي يقع فقط أثناء إختبار. القيمة الافتراضية هي 15 ثانية. |
3,4 | 0x238 | انتهت صلاحية مؤقت إرسال الاستقبال بعد المزامنة PIAFS T002. يبدأ هذا المؤقت عند إرسال إطار إستقبال مزامنة، ويتوقف عند اكتشاف إستقبال مزامنة (حالة تصادم) أو إطار تحكم. هذا خطأ سيحدث فقط عندما ال MICA ميناء يعمل كنادل (إجابة أسلوب)، أي يكون العادي تشغيل أسلوب. القيمة الافتراضية هي 15 ثانية. |
3,4 | 0x239 | انتهت صلاحية مؤقت انتظار T003 الخاص بمزامنة PIAFS. يبدأ هذا المؤقت عند الكشف عن أخطاء FCS المستمرة، ويتوقف عند الكشف عن إطار طلب مزامنة صالح. هذا خطأ يقع فقط مع ال MICA ميناء يعمل كنادل (جواب أسلوب)، أي يكون العادي عملية أسلوب. القيمة الافتراضية هي 15 ثانية. |
3,4 | 0x23a | انتهت صلاحية مؤقت PIAFS T101: مؤقت انتظار تأكيد إطار التحكم. يبدأ عند إرسال طلب إطار التحكم أو الإخطار، ويتوقف عند تأكيد الإطار. هذا خطأ فقط يقع عندما ال MICA ميناء يعمل كزبون أو بادئ، أي يقع فقط أثناء إختبار (عشرة ثاني). |
3,4 | 0x23b | PIAFS: تم إستلام FBI (ACK sequence #) خارج النطاق الذي تم التفاوض عليه، أو تم إستلام FBI=0 مع إطار بيانات غير فارغ. |
3,4 | 0x23c | PIAFS: تم إستلام FFI (MSG Sequence #) خارج النطاق الذي تم التفاوض عليه، أو FFI=0. |
3,4 | 0x23d | PIAFS: نافذة البيانات التي تم التفاوض عليها أقل من قيمة RTF (تأخير الذهاب والعودة). لم يعد Portware ينشر هذا الخطأ، ولا يجب رؤيته أبدا. |
3,4 | 0x23e | PIAFS: حقل طول بيانات الرسالة كبير جدا. يجب أن تكون 0-73. |
3,4 | 0x23F | خطأ داخلي في PIAFS: قام إستدعاء SREJ بإرجاع رمز خطأ. |
3,4 | 0x240 | خطأ بروتوكول PIAFS العام. هذا اسم مخصص للأخطاء التي ليس لها سبب قطع اتصال مقترن. |
3,4 | 0x241 | فشل تفاوض بروتوكول PIAFS: لا يوجد بروتوكول (على سبيل المثال، بروتوكول نقل البيانات ذو سرعة ثابتة، نوع سرعة متغير DTP1) مقبول لكلا المحطتين. البروتوكولات غير المقبولة هي DTP Variable Speed Type3، أو بروتوكول الوقت الفعلي. |
3,4 | 0x242 | PIAFS: لم تكن قيمة RTF المقاسة (تأخير الرحلة ذهابا وإيابا) في النطاق المحدد (المقبول). |
3,4 | 0x243 | خطأ داخلي في PIAFS: حدث غير معروف في معالج الأحداث. سقط بيان المحول إلى حالته الافتراضية. |
3,4 | 0x244 | حدثت مهلة إستجابة معالج الإشارة (SP) أثناء تحول سريع في PIAFS 2.1. لم يرى cp الخاص ب MICA إستجابة تغيير السرعة خلال 200 ثانية. |
3,4 | 0x245 | رأى بروتوكول MICA معلومات تحكم غير متناسقة في هياكل التحكم المشتركة ل CP/SP. وعلى وجه الخصوص، كان المخزن المؤقت للبيانات محاطا بعلامة أو ذيل خارج حدود مخزن البيانات المؤقت (0-63). |
تم تلقي أمر MNP أو LAPM Protocol من الشريك (الفئة 3) | ||
4.5 | 0x3xx | اكتشف EC كود أوامر غير صحيح. يوجد الأمر غير المعروف الذي تم إستلامه في آخر رقمين. يتم إرسال إطار رفض إطار MNP LD أو LAP-M (FRMR) إستجابة. |
يشير شريك LAPM إلى خطأ بروتوكول MICA (الفئة 4) | ||
4,5 | 0x4xx | شروط EC المشار إليها بواسطة العميل في إطار LAP-M FRMR. السبب المعين للبت موجود في آخر رقمين. |
4,5 | 0x401 | LAPM: يقوم النظير بالإعلام عن أمر غير صحيح. تلقى المودم المضيف إطار FRMR من مودم العميل. يشير إطار FRMR الذي تم إستلامه إلى أن مودم العميل تلقى إطار تصحيح خطأ من مودم المضيف الذي يحتوي على أمر سيئ. |
4,5 | 0x403 | LAPM: يقوم النظير بالإعلام عن عدم السماح بحقل البيانات أو أن طوله غير صحيح (إطارات U). تلقى المودم المضيف إطار FRMR من مودم العميل. يشير إطار FRMR الذي تم إستلامه إلى أن مودم العميل تلقى إطار تصحيح خطأ من مودم المضيف الذي يحتوي على حقل بيانات غير مسموح به أو يحتوي على حقل بيانات ذي طول غير صحيح (إطار U). |
4,5 | 0x404 | LAPM: طول حقل بيانات تقارير النظير أكبر من N401 (الحد الأقصى لطول حقل المعلومات المحدد في V.42)، ولكنه يحتوي على تسلسل فحص الإطارات الجيد (FCS). تلقى مودم NextPort إطار FRMR من مودم العميل. يشير إطار FRMR الذي تم إستلامه إلى أن مودم العميل تلقى إطار تصحيح خطأ من NextPort يحتوي على طول حقل بيانات أكبر من الحد الأقصى لعدد الثمانيات التي يمكن نقلها في حقل المعلومات (N401) من إطار I أو إطار SREJ أو إطار XID أو إطار واجهة مستخدم أو إطار إختبار. تسلسل التحقق من الإطارات جيد. |
4,5 | 0x408 | LAPM: يبلغ النظير عن رقم تسلسل تلقي غير صحيح أو N(R). تلقى المودم المضيف إطار FRMR من مودم العميل. يشير إطار FRMR الذي تم إستلامه إلى أن مودم العميل تلقى إطار تصحيح خطأ من مودم المضيف الذي يحتوي على رقم تسلسل إستقبال غير صالح. |
يشير شريك MNP إلى عدم الاتصال أو خطأ بروتوكول MICA (الفئة 5) | ||
4,5 | 0x5xx | شروط EC المشار إليها بواسطة العميل في إطار MNP LD. حقل السبب موجود في آخر رقمين |
3 | 0x501 | MNP: لم يحصل النظير على إطار LR. تلقى المودم المضيف إطار LD من مودم العميل. يشير إطار LD المستلم إلى أن مودم العميل لم يتلق أبدا طلب إرتباط من مودم المضيف. |
3 | 0x502 | MNP: تحتوي تقارير النظير لإطار LR على معلمة غير صحيحة #1. تلقى المودم المضيف إطار LD من مودم العميل. يشير إطار LD المستلم إلى أن مودم العميل استلم إطار طلب إرتباط من مودم المضيف الذي يحتوي على PARAM1 سيئ (أي غير متوقع). أحلت ل كثير معلومة على PARAM1 ال V.42 مواصفة. |
3 | 0x503 | MNP: يعد إطار تقارير النظير LR غير متوافق مع التكوين الخاص به. تلقى المودم المضيف إطار LD من مودم العميل. يشير إطار LD المستلم إلى أن مودم العميل استلم إطار LR من مودم المضيف غير متوافق مع مودم العميل، وهو تكوين. |
4,5 | 0x504 | الحزب القومي الأسترالي: تقارير الأقران تشير إلى عدد كبير جدا من عمليات إعادة الإرسال المتتالية عبر المفوضية الأوروبية. تلقى المودم المضيف إطار LD من مودم العميل. يشير إطار LD المستلم إلى أن مودم العميل قد تلقى العديد من عمليات إعادة الإرسال المتتالية. |
4,5 | 0x505 | انتهت صلاحية مؤقت عدم النشاط لتقارير الأقران. تلقى المودم المضيف إطار LD من مودم العميل. يشير إطار LD المستلم إلى أن مضيف مودم العميل (DTE) لم يقم بتمرير البيانات إلى مودم العميل خلال فترة من الوقت. |
3 | 0x506 | خطأ في تقارير الأقران. تلقى المودم المضيف إطار LD من مودم العميل. يشير إطار LD المستلم إلى أن مودم العميل تلقى خطأ بروتوكول MNP. |
3 | 0x5FF | قطع اتصال MNP العادي. تلقى المودم المضيف إطار LD من مودم العميل. يشير إطار LD المستلم إلى إنهاء MNP عادي، مما يشير إلى أن DTR الخاص بمودم العميل قد أسقط أو أنه استلم أمر +++ أو ATH. يحدث سبب قطع الاتصال هذا في إعداد المكالمات ووضع البيانات (0x65FF، 0x85FF، 0xA5FF). تلقى المودم المضيف LD، وهو ما يشير إلى الإنهاء العادي. تم إنهاء المكالمة بشكل طبيعي مع مسح مناسب لأسفل من جانب العميل (على سبيل المثال، تم إرسال حزمة قطع الاتصال من مودم العميل إلى مودم المضيف). قام مودم العميل بإسقاط DTR والتفاوض بشكل نظيف على بروتوكول مسح. |
يشير شريك PIAFS إلى عدم الاتصال أو خطأ في بروتوكول MICA (الفئة 6) | ||
3,4 | 0x6xx | تلقت MICA إصدار بيانات PIAFS DataLinkRelease (PDLR) مع السبب xx (انظر القيم التفصيلية أدناه). |
3,4 | 0x61x | الفئة العادية ل PIAFS DataLinkRelease (PDLR): 0 - الإصدار العادي. 1 - حظر الإصدار العادي واستمرار ربط البيانات. 2 - الإصدار العادي، إستمرار ربط البيانات. ... فئات عادية أخرى - فئات غير معرفة خاصة ببعض الأجهزة العميلة. |
3,4 | 0x62x | إستخدام الموارد غير ممكن لفئة PIAFS DLR (حالات الانشغال): 8 - DTE مشغول. 9 - العرقلة المؤقتة. ... إستخدام الموارد الأخرى ليست فئات ممكنة - فئات غير معرفة خاصة ببعض أجهزة العميل. |
3,4 | 0x63x | إستخدام الخدمة غير ممكن لفئة PIAFS DLR (معلمات غير صحيحة). 9 - يتعذر إعداد معلمة الطلب. أ - يتعذر حاليا إعداد معلمة الطلب. .. إستخدام الخدمة الأخرى ليس فئات ممكنة - فئات غير معرفة خاصة ببعض أجهزة العميل. |
3,4 | 0x64x | لم توفر الخدمة بعد الفئة ل PIAFS DLR 1 - لم يتم بعد توفير إشارة المعلمة. ... لم توفر "الخدمة الأخرى" بعد فئات - فئات غير معرفة خاصة ببعض أجهزة العميل. |
3,4 | 0x65x | فئة محتوى معلومات غير صالحة ل PIAFS DLR 8 - السمة الطرفية غير متطابقة. ... فئات محتوى معلومات غير صحيحة أخرى - فئات غير معرفة خاصة ببعض أجهزة العميل. |
3,4 | 0x66x | فئة خطأ التسلسل ل PIAFS DLR 0 - المعلمات الأساسية غير كافية. 1 - محتوى المعلومات غير محدد أو لم يقدم بعد. 5 - شرط ARQ وإشارة لا تتطابق. 6 - انتهاء صلاحية المؤقت. ... فئات أخطاء تسلسل أخرى - فئات غير معرفة خاصة ببعض أجهزة العميل. |
3,4 | 0x67x | فئة ميزات أخرى ل PIAFS DLR 1 - أثناء الاتصال الصوتي. ... فئات أخرى غريبة- فئات غير معرفة خاصة ببعض الأجهزة العميلة. |
المضيف/IOS المطلوب قطع الاتصال (الفئة 31) | ||
6,7 | 0x1fxx | بدأ المضيف قطع الاتصال. القيمة هي مجموع 0x1F00 وقيمة SessionStopCommand. هذا هو سبب إنهاء المضيف الآخر. ويشار إلى سبب المضيف في وحدات البايت xx منخفضة الترتيب. |
3,6,7 | 0x1f00 | قام مضيف غير محدد ببدء قطع الاتصال. القيمة هي مجموع 0x1F00 وقيمة SessionStopCommand. هذا هو سبب قطع الاتصال الذي بدأه IOS بأكمله. يتم إستخدامه لجميع عمليات قطع الاتصال غير القياسية. على سبيل المثال، قد يكون هذا نتيجة لقرار برنامج إدارة المودم إنهاء المكالمة. أحد التفسيرات المحتملة هو بروتوكول RADIUS لفشل المصادقة على مستوى أعلى أو TACACS أو تطبيق آخر يصدر إسقاط DTR إلى مودم المضيف. لن يتم حساب هذا النوع من قطع الاتصال نحو CSR عندما يكون مودم المضيف في وضع البيانات. |
3 | 0x1f01 | كان الرقم المطلوب مشغولا. حدث قطع الاتصال لأن المضيف يشير إلى أن الرقم المطلوب مشغول. |
3 | 0x1f02 | الرقم المطلوب لم يجب. حدث قطع الاتصال لأن المضيف يشير إلى أن الرقم المطلوب لم يجب. |
3,6,7 | 0x1f03 | تم إسقاط DTR الظاهري. تنعكس هذه الحالة من معيد توجيه منفذ الإدخال/الإخراج الذي يستخدم المودم حاليا. حدث قطع الاتصال لأن المضيف قام بإسقاط خط DTR الظاهري. يبدأ برنامج Cisco IOS software سبب قطع الاتصال العام هذا. الأسباب المحتملة هي مهلة الخمول، PPP LCP TERMREQ المتلقاة، فشل المصادقة، Telnet hangup، وهكذا. لتحديد سبب التعليق، قم بفحص سبب قطع اتصال Radius من الأمر الثالث لسجل اتصال المودم أو من المصادقة والتفويض والمحاسبة (AAA). |
6,7 | 0x1f04 | تم اكتشاف الأمر ATH (hangup) بواسطة المضيف المحلي. |
3 | 0x1f05 | لا يوجد وصول إلى شبكة Telco. حدث قطع الاتصال بسبب تعذر وصول المضيف إلى الشبكة (ISDN). |
3,4,5 , | 0x1f06 | أشارت الشبكة إلى قطع الاتصال. يمكن أن يحدث ذلك قبل وضع البيانات أو خلاله. يعني قطع الاتصال A 0x1f06 أن IOS تلقى إشارة ربط الدائرة من شبكة الدائرة (أي قطع اتصال Q.931 أو إشارة CAS Onhook)، وقد قام IOS بإعلام MICA بذلك عندما أمر MICA بالتوقف. إذا وصلت MICA إلى وضع البيانات ولم يتم التفاوض بشأن بروتوكول EC (LAPM أو MNP4)، فقد يكون هذا قطع اتصال عادي. يمكن أيضا إنشاء هذا السبب عندما يتم إلغاء إلغاء الأمر لمستخدمي شبكة الطلب الهاتفي (DUN) لنظام التشغيل Windows 95 أو 98 أثناء التدريب وقبل أن تصل المكالمة إلى حالة مستقرة. أيضا، إذا كان العميل على نحو مفاجئ أن يفك خط الهاتف/إيقاف تشغيل المودم، بعد ذلك يعتبر سبب قطع الاتصال هذا طبيعيا. ومع ذلك، إذا تفاوض الاتصال مع EC (LAPM أو MNP4)، وبالتالي في وضع البيانات، يمكن إنشاء سبب قطع الاتصال هذا عن طريق قطع اتصال تالف (أي قطع اتصال لا يعتبر إنهاء مكالمة لطيفا). وذلك نظرا لحقيقة أنه في حالة قيام DTE العميل (في وضع البيانات) بقطع اتصال المكالمة بشكل منظم (مع DTR drop أو +++/ATH)، سيقوم مودم العميل بإرسال قرص LAPM (أو MNP LD) لنا قبل أن يتم تشغيله، وبالتالي توليد سبب انقطاع 0x220 بدلا من 0x1f06. أشارت الشبكة إلى أن انقطاع الاتصال، في هذه الحالة، ربما يدل على وجود مودم عميل غير سعيد، الذي قرر أنه لم يعد قادرا على دعم الناقل لسبب ما. |
3 | 0x1f07 | قام NAS بإنهاء تشغيل SS7/COT. حدث قطع الاتصال لأن NAS قام بإنهاء عملية SS7/COT (إختبار الاستمرارية). |
3 | 0x1f08 | تم إنهاء عملية SS7/COT بواسطة الموجه بسبب انتهاء مهلة T8/T24. |
- | 0x1fff | غير مطلوب. إنهاء. يرسل المضيف سبب قطع الاتصال هذا عندما يستلم رسالة إنهاء غير مرغوب فيها. |
سبب قطع الاتصال:الأنواع تصف وقت حدوث قطع اتصال الاتصال بالفعل. يمكن تصنيفها إلى نوعين رئيسيين: أثناء إعداد المكالمات وأثناء وضع البيانات (حالة ثابتة). يحدد الجدول التالي أنواع أسباب قطع الاتصال الأكثر شيوعا وقيمها كما هو موضح في سبب قطع الاتصال.
نوع قطع الاتصال | نوع قطع الاتصال (سداسي عشر) | الوصف |
---|---|---|
0 | 0x0... | (غير مستخدم) |
1 | 0x2... | (غير مستخدم) |
2 | 0x4... | حالات أخرى. |
3 | 0x6... | حدثت حالة أثناء إعداد المكالمة. |
4 | 0x8... | في وضع البيانات. موافق مسح بيانات Rx (من السطر إلى المضيف). حدثت حالة قطع الاتصال في وضع البيانات. تحاول MICA تسليم أي بيانات تم تلقيها إلى المضيف (IOS). بالنسبة لبعض عمليات قطع الاتصال (على سبيل المثال، PIAFS)، هذا هو نوع وضع البيانات الوحيد المستخدم، ولم يتم إجراء أي إشارة إلى إتجاه سحب البيانات. |
5 | 0×a... | في وضع البيانات. تدفق بيانات Rx (من سطر إلى مضيف) ليس موافق. حدثت حالة قطع الاتصال في وضع البيانات. تحاول MICA تسليم أي بيانات تم تلقيها إلى المضيف (IOS). في كود MICA القديم، يكون هذا النوع مكافئا للنوع 4 أعلاه. وعلى الرغم من أن برنامج IOS يعرض حالات قطع الاتصال هذه على أنها ليست "موافق"، إلا أنه لم تحدث أي مشاكل بالفعل. |
6 | 0×س... | في وضع البيانات. موافق مسح بيانات Tx (من المضيف إلى الخط). حدثت حالة قطع الاتصال في وضع البيانات. تحاول MICA إرسال بيانات المضيف (IOS) المخزن مؤقتا إلى المودم الشريك. |
7 | 0xE.. | في وضع البيانات. تدفق بيانات Tx (من المضيف إلى السطر) غير موافق. حدثت حالة قطع الاتصال في وضع البيانات. تحاول MICA إرسال بيانات المضيف (IOS) المخزن مؤقتا إلى المودم الشريك. في كود MICA القديم، يكون هذا النوع مكافئا للنوع 6 أعلاه. وعلى الرغم من أن برنامج IOS يعرض حالات قطع الاتصال هذه على أنها ليست "موافق"، إلا أنه لم تحدث أي مشاكل بالفعل. |