فهم معلومات مهمة حول أوامر التصحيح
المحتويات
المقدمة
يصف هذا المستند الإرشادات العامة حول استخدام أوامر التصحيح بما في ذلك الأمر debug ip packet المتوفر على أنظمة Cisco IOS® الأساسية.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
-
يتم الاتصال بالموجه باستخدام منافذ وحدة التحكم والمنافذ (AUX) و vty.
-
مشاكل تكوين IOS العامة من Cisco.
-
تفسير مخرجات تصحيح أخطاء Cisco IOS.
المكونات المستخدمة
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يزود هذا وثيقة مبادئ التوجيهية العامة لاستخدام يضبط أمر على cisco ios ® منصة. كما يتضمن أمثلة ولمحة عامة عن تصحيح الأخطاء المشروط.
توفر أوامر EXEC ذات الامتيازات debug معلومات تشخيصية حول أحداث الشبكة وحالة البروتوكول ومعالجة الحزمة ونشاط الشبكة العام. تساعد هذه الأوامر في تحديد سبب مشاكل معينة أثناء أستكشاف الأخطاء وإصلاحها.
ومع ذلك، يمكن أن تقوم أوامر تصحيح الأخطاء بإنشاء كمية كبيرة من معلومات الإخراج ويمكن أن تؤثر على أداء الجهاز، وخاصة على الموجهات التي تعالج حركة مرور البيانات المرتفعة أو إستخدام وحدة المعالجة المركزية (CPU) بشكل كبير. لهذا السبب، قم بتشغيل أوامر تصحيح الأخطاء بعناية وعندما تكون هناك حاجة إليها لاستكشاف الأخطاء وإصلاحها.
ملاحظة: لا يشرح هذا المستند كيفية إستخدام أوامر تصحيح أخطاء معينة وإخراجها أو تفسيرها. للحصول على تفاصيل حول أوامر تصحيح الأخطاء الفردية، ارجع إلى وثائق مرجع أمر تصحيح الأخطاء المناسبة من Cisco.
التحذيرات
قم بتشغيل أوامر تصحيح الأخطاء بحذر. بشكل عام، أستخدم هذه الأوامر فقط تحت توجيه ممثل الدعم الفني لديك عند أستكشاف أخطاء معينة وإصلاحها.
يمكن أن يؤدي تمكين تصحيح الأخطاء إلى تعطيل عملية الموجه، وخاصة عندما تكون الشبكة تحت حمل ثقيل. في حالة تمكين التسجيل، يمكن لخادم الوصول تجميد البيانات بشكل متقطع عندما يصبح منفذ وحدة التحكم محملا أكثر من اللازم برسائل السجل.
قبل تشغيل أمر تصحيح الأخطاء، ضع في الاعتبار مقدار الإخراج الذي يمكن أن ينتجه الأمر ومدة تشغيل جلسة تصحيح الأخطاء.
على سبيل المثال، على موجه مزود بواجهة معدل أساسي واحدة، من غير المرجح أن يؤثر debug isdn q931 على النظام. ومع ذلك، يمكن أن يؤدي تشغيل أمر تصحيح الأخطاء نفسه على AS5800 بتكوين كامل E1 إلى توليد إخراج كاف لجعل الجهاز معلقا أو يتوقف عن الاستجابة.
قبل تصحيح الأخطاء، تحقق من حمل وحدة المعالجة المركزية (CPU) من خلال تشغيل أمر show process cpu. تحقق من توفر سعة كافية لوحدة المعالجة المركزية (CPU) قبل تمكين تصحيح الأخطاء، فهذه هي الطريقة.
على سبيل المثال، إذا كان موجه Cisco 7200 مزود بواجهة ATM قيد التشغيل مع التوصيل، فإن إعادة تشغيل الموجه يمكن أن يستهلك موارد كبيرة لوحدة المعالجة المركزية، حسب عدد الواجهات الفرعية التي تم تكوينها. لكل دائرة ظاهرية (VC)، يجب إنشاء حزمة وحدة بيانات بروتوكول الجسر (BPDU). قد يؤدي تمكين تصحيح الأخطاء أثناء هذه الفترة الحرجة إلى زيادة إستخدام وحدة المعالجة المركزية (CPU) بشكل كبير، مما قد يؤدي إلى تعليق الجهاز أو فقدان اتصال الشبكة.
ملاحظة: عند تشغيل تصحيح الأخطاء، لا ترى عادة موجه الأمر Router، وخاصة عندما يكون تصحيح الأخطاء مكثفا. ومع ذلك، في معظم الحالات، يمكنك تشغيل أوامر no debug all أو undebug all لإيقاف تصحيح الأخطاء.
قبل التصحيح
بالإضافة إلى النقاط المذكورة أعلاه، تأكد من فهمك لتأثير تصحيح الأخطاء على إستقرار النظام الأساسي. يجب أيضا مراعاة الواجهة الموجودة على الموجه التي يجب عليك الاتصال بها قبل تمكين أي أمر تصحيح أخطاء.
الحصول على مخرجات تصحيح الأخطاء
يمكن للموجهات عرض مخرجات تصحيح الأخطاء على واجهات مختلفة، بما في ذلك منافذ وحدة التحكم والمنافذ (AUX) و vty. يمكن للموجهات أيضا تسجيل الرسائل إلى مخزن مؤقت داخلي إلى خادم syslog خارجي ل UNIX.
منفذ وحدة التحكم
إذا كنت متصلا بوحدة التحكم ضمن التكوينات العادية، فلا حاجة إلى القيام بعمل إضافي. يجب عرض إخراج تصحيح الأخطاء تلقائيا. ومع ذلك، تأكد من تعيين مستوى وحدة تحكم التسجيل على النحو المطلوب ومن عدم تعطيل التسجيل باستخدام الأمر no logging console.
تحذير: يمكن أن يؤدي تصحيح الأخطاء المفرط إلى منفذ وحدة التحكم بالموجه إلى تعليقه. وذلك لأن الموجه يقوم تلقائيا بأولوية إخراج وحدة التحكم قبل وظائف الموجهات الأخرى. إذا كان الموجه يقوم بمعالجة إخراج تصحيح أخطاء كبير إلى منفذ وحدة التحكم، فيمكن تعليقه. إذا كان إخراج تصحيح الأخطاء زائدا، فاستخدم منافذ vty (telnet) أو المخازن المؤقتة للسجل للحصول على تصحيح أخطائك.
ملاحظة: بشكل افتراضي، يتم تمكين التسجيل على منفذ وحدة التحكم. يعالج منفذ وحدة التحكم إخراج تصحيح الأخطاء دائما حتى إذا كنت تستخدم بعض المنافذ أو الطرق الأخرى (مثل aux أو vty أو buffer) لالتقاط الإخراج. توصيك Cisco ضمن ظروف التشغيل العادية، بتشغيل الأمر no logging console ويتم تمكينه في جميع الأوقات واستخدام طرق أخرى لالتقاط تصحيح الأخطاء. في الحالات التي يجب أن تستخدم فيها وحدة التحكم، قم بتشغيل وحدة تحكم التسجيل مرة أخرى مؤقتا.
المنفذ (AUX) المساعد
إذا كنت متصلا عبر منفذ مساعد، قم بتشغيل الأمر terminal monitor. تحقق أيضا من عدم تنشيط الأمر theno logging on على الموجه.
ملاحظة: إذا كنت تستخدم المنفذ (AUX) المساعد لمراقبة الموجه، فاضع في الاعتبار عند إعادة تمهيد الموجه، فإن المنفذ (AUX) لا يعرض إخراج تسلسل التمهيد. قم بالاتصال بمنفذ وحدة التحكم لعرض تسلسل التمهيد.
منافذ vty
إذا كنت متصلا عبر منفذ مساعد أو عبر برنامج Telnet، فاكتب الأمر terminal monitor. تحقق أيضا من عدم إستخدام الأمر no logging on.
تسجيل الرسائل إلى مخزن مؤقت داخلي
جهاز التسجيل الافتراضي هو وحدة التحكم؛ يتم عرض جميع الرسائل على وحدة التحكم ما لم يتم تحديد خلاف ذلك.
لتسجيل الرسائل إلى مخزن مؤقت داخلي، قم بتشغيل أمر تكوين الموجه المخزن مؤقتا. هذه هي الصياغة الكاملة لهذا الأمر:
logging buffered no logging buffered
يقوم الأمر الذي يتم تحميله مؤقتا بنسخ رسائل السجل إلى مخزن مؤقت داخلي بدلا من كتابتها إلى وحدة التحكم. المخزن المؤقت دائري بطبيعته، لذا فإن الرسائل الأحدث تقوم باستبدال الرسائل القديمة.
لعرض الرسائل المسجلة في المخزن المؤقت، أستخدم أمر EXEC للمستوى المتميز show logging. الرسالة الأولى المعروضة هي أقدم رسالة في المخزن المؤقت. يمكنك تحديد حجم المخزن المؤقت ومستوى خطورة الرسائل التي سيتم تسجيلها.
ملاحظة: تأكد من توفر ذاكرة كافية في المربع قبل إدخال حجم المخزن المؤقت. أستخدم الأمر show proc mem لعرض الذاكرة المتوفرة لديك.
يقوم الأمر no logging buffered بإلغاء إستخدام المخزن المؤقت وكتابة الرسائل إلى وحدة التحكم (الإعداد الافتراضي).
تسجيل الرسائل إلى خادم UNIX Syslog
لتسجيل الرسائل إلى مضيف خادم syslog، قم بتشغيل أمر تكوين موجه التسجيل. عرض الصياغة الكاملة لهذا الأمر:
loggingno logging
يحدد الأمر logging مضيف خادم syslog لتلقي رسائل التسجيل. الوسيطة <ip-address> هي عنوان IP الخاص بالمضيف. بإصدار هذا الأمر أكثر من مرة، يمكنك إنشاء قائمة بخوادم syslog التي تستلم رسائل التسجيل.
يحذف الأمر theno logging خادم syslog باستخدام العنوان المحدد من قائمة syslogs.
مهام تصحيح الأخطاء السابقة الأخرى
-
قم بإعداد برنامج المحاكي الطرفي بحيث يلتقط إخراج تصحيح الأخطاء إلى ملف. ارجع إلى وثائق المحاكي الطرفي للبرامج.
-
تمكين الطوابع الزمنية بالمللي ثانية (msec) التي تشغل أمر الطوابع الزمنية للخدمة:
router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
تقوم هذه الأوامر بإضافة الطوابع الزمنية لتصحيح الأخطاء بالتنسيق MMM DD HH:MM:SS، مما يشير إلى التاريخ والوقت وفقا لساعة النظام. إذا لم يتم تعيين ساعة النظام، فإن التاريخ والوقت يسبقهما علامة نجمية (*) للإشارة إلى أن التاريخ والوقت غير صحيحين على الأرجح.
من المستحسن بشكل عام تكوين الطوابع الزمنية بالمللي ثانية لأن ذلك يوفر مستوى مرتفعا من الوضوح عند مراجعة مخرجات تصحيح الأخطاء. توفر الطوابع الزمنية بالمللي ثانية إشارة أفضل إلى توقيت مختلف أحداث تصحيح الأخطاء المتعلقة ببعضها البعض. ومع ذلك، عندما ينتج عن منفذ وحدة التحكم العديد من الرسائل، فإنه لا يمكن ربطها بالتوقيت الفعلي للحدث.
على سبيل المثال، إذا قمت بتمكين تصحيح الأخطاء x25all على مربع يحتوي على 200 VCs، وتم تسجيل الإخراج إلى المخزن المؤقت (الذي يقوم بتشغيل أوامر وحدة تحكم التسجيل والتسجيل المخزن مؤقتا)، فإن الطابع الزمني المعروض في إخراج تصحيح الأخطاء (داخل المخزن المؤقت) لا يمكن أن يكون الوقت الدقيق الذي تمر فيه الحزمة عبر الواجهة. لذلك، لا تستخدم الطوابع الزمنية ل MSEC لإثبات مشاكل الأداء، ولكن للحصول على معلومات نسبية حول وقت حدوث الأحداث.
إيقاف تصحيح الأخطاء
لإيقاف تصحيح الأخطاء، أستخدم الأمر no debug all أو undebug all. تحقق من إيقاف تشغيل تصحيح الأخطاء باستخدام الأمر show debug.
تذكر الأوامر no logging console وterminal no monitor فقط تمنع المخرجات من أن تصبح مخرجات على وحدة التحكم، aux أو vty على التوالي. لا تقوم بإيقاف تصحيح الأخطاء وتستخدم موارد الموجه.
إستخدام أمر debug ip packet
في موجهات Cisco IOS® الكلاسيكية، ترى حزمة IP debug حركة مرور البيانات التي يتم تحويلها للعملية بشكل رئيسي. لا تظهر حركة المرور التي تمت إعادة توجيهها عبر التحويل السريع أو إعادة التوجيه السريع ما لم يتم فرض إعادة التوجيه إلى مسار تحويل العملية. مهما، لأن هو يلد إنتاج لكل ربط، الإنتاج يستطيع كنت واسع ويسبب المسحاج تخديد أن يعلق. ولهذا السبب، قم بتشغيل حزمة IP الخاصة بتصحيح الأخطاء فقط تحت أكثر عناصر التحكم صرامة كما هو موضح في هذا القسم.
أفضل طريقة للحد من إخراج حزمة IP للتصحيح هي إنشاء قائمة وصول مرتبطة بتصحيح الأخطاء. يمكن فقط إخضاع الحزم التي تطابق معايير قائمة الوصول إلى حزمة IP debug. لا يلزم تطبيق قائمة الوصول هذه على أي واجهة، بل يتم تطبيقها على عملية تصحيح الأخطاء.
قبل تشغيل حزمة IP الخاصة بتصحيح الأخطاء، لاحظ أن الموجه يستخدم التحويل السريع بشكل افتراضي، أو يمكن أن يستخدم تحويل CEF إذا تم تكوينه للقيام بذلك. هذا يعني أنه بمجرد وجود هذه التقنيات، لا يتم توفير الحزمة للمعالج، ولا يظهر تصحيح الأخطاء أي شيء. لكي يعمل هذا، يجب تعطيل التحويل السريع على الموجه دون وجود ip route-cache (لحزم البث الأحادي) أو بدون ip route-cache (لحزم البث المتعدد). يجب تطبيق هذا على الواجهات التي يفترض أن تتدفق فيها حركة المرور. تحقق من ذلك باستخدام الأمر show ip route.
ملاحظة: على الأنظمة الأساسية الأحدث، تتم معالجة إعادة التوجيه بشكل نموذجي بواسطة التحويل القائم على الأجهزة أو CEF، لذلك لم يعد تعطيل التحويل السريع قابلا للتطبيق أو مستحسنا. ونتيجة لذلك، يمكن أن يفشل تصحيح أخطاء حزمة IP في عرض حركة مرور النقل بشكل موثوق، ويعتمد أستكشاف الأخطاء وإصلاحها الحديث عادة على التقاط خاص بالنظام الأساسي أو أدوات أجهزة بدلا من ذلك.
تصحيح الأخطاء المؤهل
عندما يتم تمكين ميزة تصحيح الأخطاء المشروطة، يقوم الموجه بإنشاء رسائل تصحيح الأخطاء للحزم التي تدخل الموجه أو تخرج منه على واجهة محددة؛ لا يقوم الموجه بإنشاء إخراج تصحيح الأخطاء للحزم التي تدخل أو تخرج من خلال واجهة مختلفة.
انظر إلى تطبيق بسيط للتصحيح الشرطي. تأمل في هذا السيناريو: يحتوي الموجه الظاهر بعد ذلك (trabol) على واجهتين (تسلسلية 0 و serial 3) كلاهما يشغلان تضمين HDLC.
يمكنك تشغيل أمر الواجهة التسلسلية لnormaldebug لمراقبة رسائل keepalive الخاصة ب HDLC التي يتم استقبالها على جميع الواجهات. أنت يستطيع راقبت ال keepalives على كلا قارن:
traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up ! -- HDLC keeplaive on interface Serial 0 *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up ! -- HDLC keeplaive on interface Serial 3 *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up
قم بتمكين تصحيح الأخطاء الشرطي للواجهة serial 3، مما يعني عرض تصحيح الأخطاء فقط للواجهة التسلسلية 3. قم بتشغيل واجهة تصحيح الأخطاء <interface_type interface_number >الأمر:
traxbol#debug interface serial 3 Condition 1 set
قم بتشغيل الأمر show debug condition للتحقق من أن تصحيح الأخطاء الشرطي نشط (يكون شرط للواجهة serial 3 نشطا):
traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#
يتم الآن عرض تصحيح الأخطاء للواجهة التسلسلية 3 فقط:
*Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up
قم بتشغيل الأمر undebug interface <interface_type interface_number> لإزالة تصحيح الأخطاء الشرطي. من المستحسن إيقاف تشغيل تصحيح الأخطاء (على سبيل المثال، باستخدام إلغاء تصحيح الأخطاء الكل) قبل إزالة المشغل الشرطي. هذا لتجنب طوفان من مخرجات تصحيح الأخطاء عند إزالة الشرط.
traxbol#undebug interface serial 3 This condition is the last interface condition set. Removing all conditions can cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed traxbol
يمكنك ملاحظة تصحيح الأخطاء لكل من الواجهة serial 0 وكذلك الشاشات التسلسلية 3:
*Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up
تحذير: بعض عمليات تصحيح الأخطاء مشروطة لوحدها. والمثال على ذلك هو تصحيح أخطاء ATM، مع تصحيح أخطاء ATM، يجب عليك تحديد الواجهة التي يجب تمكين تصحيح الأخطاء لها بدلا من تمكين تصحيح الأخطاء على جميع واجهات ATM وتحديد شرط.
يوضح هذا القسم الطريقة الصحيحة للحد من تصحيح حزم ATM إلى واجهة فرعية واحدة:
arielle-nrp2#debug atm packet interface atm 0/0/0.1 !--- Note that you explicitly specify the sub-interface to be used for debugging ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2#
إذا حاولت تمكين تصحيح أخطاء ATM على جميع الواجهات (بحالة مطبقة)، يمكن أن يعلق الموجه إذا كان يحتوي على عدد كبير من واجهات ATM الفرعية. يتم عرض مثال على الطريقة غير الصحيحة لتصحيح أخطاء ATM.
في هذه الحالة يمكنك أن ترى أن شرط مطبق لكنك أيضا ترى أن هذا ليس له تأثير. أنت يستطيع بعد رأيت الربط من الآخر قارن.
في سيناريو هذا المختبر، لديك فقط واجهتين وحركة مرور قليلة جدا. إذا كان عدد الواجهات مرتفعا، فإن إخراج تصحيح الأخطاء لجميع الواجهات يكون أيضا مرتفعا للغاية ويمكن أن يتسبب في تعليق الموجه:
arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1 ! -- A condition for a specific interface. arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O): ! -- You see debugs from interface ATM0/0/0/.2, even though the condition ! -- specified ONLY AT0/0/0.1 VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O): !--- You also see debugs for interface ATM0/0/0.1 as you wanted. VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
5.0 |
22-Jun-2026
|
مسافة مقدمة محدثة، مسافات أخرى ضمن المقالة، القواعد، التدقيق الإملائي، الإزاحة. |
4.0 |
19-Aug-2024
|
تقويم |
2.0 |
29-Apr-2022
|
تم تحديث الارتباطات المقطوعة وإزالتها. |
1.0 |
02-Dec-2013
|
الإصدار الأولي |
التعليقات