المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

الاصطلاحات

تحديد حالة المودم

تحديد سبب قطع الاتصال

سجلات مكالمات المودم

سجلات محاسبة AAA

يعرض الأمر show modem operation-status وأبديه modem log commands

تنسيق سبب قطع الاتصال

حالات مودم MICA

أسباب قطع اتصال مودم MICA

سبب قطع الاتصال: الأنواع

معلومات ذات صلة

المقدمة

يوضح هذا المستند كيفية تفسير أكواد أسباب قطع الاتصال التي تم الإبلاغ عنها بواسطة أجهزة مودم تجميع قناة 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). يمكن الإبلاغ عن أسباب قطع الاتصال هذه باستخدام ثلاث طرق أساسية:

1. سجلات مكالمات المودم: تشير هذه التقارير إلى أسباب انقطاع كل من برنامج IOS® ومودم MICA.

2. سجلات محاسبة AAA: هذا التقرير فقط سبب قطع اتصال برنامج IOS.

3. أوامر 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

كما يمكن إستخدام سجلات محاسبة 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 المستندة إلى الخادم.

يعرض الأمر show modem operation-status وأبديه modem log commands

يمكن إستخدام أوامر 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 الأساسية.

حالات مودم MICA

الحالة

الوصف

وضع الخمول (#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)

في هذه الحالة، يمكن لجلسة عمل المودم تمرير البيانات على الارتباط. الدولة المستقرة يتم دخولها من الدولة المتفاوضة الواقعة ضمن المجموعة الأوروبية:

- عند تفاوض البروتوكول الناجح (كما تم تكوينه).

- من حالات إعادة التدريب الثابتة والمنتظمة_الولاية_تغير السرعة، حيث تتم إعادة التفاوض بنجاح على الرابط المادي.

- في وضع الفاكس؛ تعني هذه الحالة أن محرك T30 قيد التشغيل. أثناء مكالمة فاكس، هناك تحول بين Steady_STATE إلى Steady_STATE_ESCAPE. يمثل هذا الأمر مكالمة الفاكس التي تمر بمراحلها المختلفة لجلسة عمل الفاكس (T30).

Steady_State_Retraining (#35)

في هذه الحالة، يتم حاليا إعادة تدريب جلسة عمل المودم. تكون حالة إعادة التدريب الثابت من الحالة المستقرة أو من الحالة المستقرة_الحالة_التي تتحول فيها السرعة هي:

- على الأمر Host Link_Control - [إعادة التدريب].

- عن طريق تخفيض حد داخلي (قابل للتكوين).

Steady_state_shiftSpeed (#40)

في هذه الحالة، تحول جلسة عمل المودم السرعة حاليا. وعندها تدخل حالة الثبات_الحالة_المحول للسرعة من حالة الثبات:

- على Host_LINK_CONTROL - [إحتياطي، توجيه].

- عن طريق تخفيض حد داخلي (قابل للتكوين).

Steady_State_Escape (#45)

في هذه الحالة، لا يزال المودم متصلا مع النظير البعيد، ولكن واجهة المضيف في وضع الأمر AT. يتم إدخال هذه الحالة فقط عند تلقي تسلسل هروب صالح من Hayes. في وضع الفاكس، تعني هذه الحالة أن محرك T30 يقبل أوامر AT من المضيف. راجع حالة (#30) الثابت للحصول على معلومات حول مكالمة فاكس.

إنهاء (#50)

في هذه الحالة، تحاول جلسة عمل المودم مسح بيانات المستخدم ومسح معالج الإشارة الرقمية (DSP). في برنامج_reset، لا يوجد تدفق منظم، كما تتم إعادة تعيين DSP. يتم إدخال حالة الإنهاء من أي ولاية:

- عند LINK_TERMINATE أو Software_RESET من المضيف.

- عند فقد شركة الشحن من DSP.

- عند إستلام أمر ATH من DTE.

- عند إستلام إطار تصحيح خطأ DISK/LD (قطع الاتصال) من السطر.

- من خلال تخفيض عتبات داخلية متنوعة (قابلة للتكوين).

قيد الانتظار ( #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

يتكون سبب انقطاع مودم 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) للطلب الهاتفي الذي يتجاوز ثانية واحدة ويتسبب في عدم قدرة أجهزة المودم على تدريب أجهزة إلغاء الصدى. الأسباب الأخرى المحتملة هي:

- مستويات طاقة TX الفعلية غير صحيحة ولا يتم بعد ذلك معالجة الدرجات بواسطة الجانب البعيد.

- هناك الكثير من الضوضاء المفرطة في المرحلتين الثالثة والرابعة خلال التدريب على الفئتين V.34.

- هناك خطأ عامل التشغيل.

- يحدث تداخل في الشبكة أثناء التدريب على الإصدار 34 (يقوم شخص ما باختيار الامتداد).

هذا النوع من عدد قطع الاتصال مقابل CSR.

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 يعرض حالات قطع الاتصال هذه على أنها ليست "موافق"، إلا أنه لم تحدث أي مشاكل بالفعل.

معلومات ذات صلة

- ميكا عند مجموعة الأوامر

- ولاية ميكا عند مجموعة القيادة مع PIAFS

- ملاحظات إصدار MICA Portware

- مرجع تسجيلات NextPort AT Commands and S

- الدعم الفني - Cisco Systems