Формат SNMP-повідомлень, що вкладаються в UDP-дейтограмми.
Мал. з Протокол управління SNMP Семенов Ю.А. (ДНЦ ІТЕФ)
Не забуваємо, що використовуються ASN.1 і BER.
Масив даних, що передаються:
Перший байт, який надсилається пристрою - 30H. Це ознака типу даних Universal Sequence і зазвичай є першим байтом в BER / DER - сумісних протоколах.
У двійковому поданні 30H:
Перші два біта зліва. якщо рівні нулях, позначають універсальний запит, тобто він поширюється на всі поля. Наступний біт зліва дорівнює одиниці, це означає складовою запит. Решта біти рівні 10000B = 10H, це SEQUENCE. Отже, це Universal Sequence
Наступний байт масиву містить розмір всього пакета, крім перших двох байта.
Наступний байт дорівнює 0x02. це означає, що подальша інформація - Integer, т.е.чісло. Байт в kk [3] - довжина даних і kk [4] - дійсне значення. The 0x00 тут вказує, що версія протоколу = 1 (на одиницю менше дійсного значення SNMP v.1).
Далі слід байт 0x04. який вказує, що наступні дані - octet (8 bit) string. Потім йде байт довжини і 6 байтів кодів символів. Рядок 'public' вказує на community. цю зміну можна використовувати в якості пароля.
Байт в kk [13] - 0xa1. Його двійкове подання
Коли ліві три біта = 101. це означає, що наступні дані - Context Specific. тобто ви повинні подивитися документацію на конкретний протокол. Останні чотири біта вказують номер, який в даному випадку дорівнює 1. Отже, це Context Specific 1. В документації на SNMP - Get Next Request.
Наступний байт вказує довжину (= 24, до кінця пакету)
Наступні три байта містять Request ID. який ми встановлюємо рівним одиниці. Kk [15] = 0x02, що вказує на тип Integer. Наступний байт - довжина (= 1), потім самі дані (= 1).
Наступні три байта містять код помилки (error status) поточного з'єднання. Оскільки ми тільки почали розмову, він встановлений в нуль.
Природно, що після цього ми маємо три байта, що вказують на індекс помилки (error index). Він також встановлено в нуль.
Тепер, в kk [26] = 30H. ми маємо початок іншої структури (або sequence. якщо ви віддаєте перевагу так).
Відразу ж після першої структури ми маємо іншу. Такий формат дозволяє вам зробити два запити одночасно. Просто додайте наступне 0x30 після закінчення цієї структури і відповідні дані.
Після байта довжини ми маємо байт 0x06. який вказує на Object data type (Object Identifier). Наступний байт - довжина.
Наступні сім байт дуже важливі.
ISO, в своїй безмежній мудрості, накромсала Інтернет в деревоподібних ієрархію.
Природно, нагорі корінь (Root), потім йде ISO (1), потім org під ISO (1.3), потім Department of Defense або dod під org (1.3.6). Безпосередньо після цього ми маємо Internet (1.3.6.1), під Internet ми маємо mgmt (1.3.6.1.2) і під mgmt ми маємо MIB або the Management Information Database (1.3.6.1.2.1). Оскільки ми імпользуем SNMP, який використовується для управління мережевими системами, ми маємо system (1.3.6.1.2.1.1). Отже, за ієрархією ми знаходимося в 1.3.6.1.2.1.1. Остання 3. в kk [36], - Sysuptime під System.
Отже, байти від kk [30] до kk [36] містять ієрархію нашого запиту. Вас може трохи збити з пантелику те, що перший байт, kk [30], дорівнює 0x2b замість 1.3 як це повинно бути. Дійсно, це ISO трохи порозумнішала (одного разу!). Для економії переданих байт вони вирішили помножити першу 1 в 1.3.6.1.2.1.1.3 на 40 і скласти результат з другим числом, тобто 3. Отже, ми отримали 1 * 40 + 3 = 43 або 0x2b. Збиває з пантелику, але мудро.
Цікавий момент виходить, якщо потрібно запросити значення об'єкта з ідентифікатором виду 1.3.6.1.4.1.9585.1.0. Значення одного з субідентіфікаторов явно більше 255 (тобто в байт не вкладається). Читаємо ГОСТ.
ДСТУ ISO / IEC 8825-93.
Інформаційна технологія. Взаємозв'язок відкритих систем.
Специфікація базових правил кодування для абстрактно-синтаксичної нотації версії один (АСН.1).
22. Кодова представлення значення "ідентифікатор об'єкта".
22.1 Кодова представлення значення "ідентифікатор об'єкта" має битьпростим кодовою поданням.
22.2 Октети вмісту повинні бути (впорядкованої) послідовністю наступних один за одним кодових уявлень субідентіфікаторов (см.22.3 і 22.4).
Кожен субідентіфікатор представляється послідовністю одного або більше октетів. Біт 8 кожного октету вказує, чи є цей октет останнім в послідовності: біт 8 останнього октету повинен мати значення "нуль", а біт 8 кожного попереднього октету - значення "одиниця". Бітами 1 - 7 октетів цієї послідовності кодують субідентіфікатор. Ці групи біт, послідовно з'єднані один з одним, слід розглядати як двійкове число без знака, старшим бітом якого є біт 7 першого октету, а молодшим бітом - біт 1 останнього октету. Субідентіфікатор повинен бути закодований за допомогою найменшого можливого кількості октетів; це означає, що головний октет субідетіфікатора не повинен мати шестнадцатиричное значення 80H.
22.3 Кількість субідентіфікаторов (N) має бути на одиницю менше кількості компонентів ідентифікатора об'єкта в кодованому значенні "ідентифікатор об'єкта".
22.4 Числове значення першого субідентіфікатора обчислюється за двома першими значенням компонентів кодованого значення "ідентифікатор об'єкта" за допомогою формули
(X * 40) + Y,
де X - значення першого компонента ідентифікатора об'єкта,
а Y - значення другого компонента ідентифікатора об'єкта.
Примітка - Це "упаковане" уявлення двох перших компонентів ідентифікатора об'єкта можливо в силу того, що виділено лише три значення для ребер, що виходять з кореневої вершини, і не більше 39 наступних значень - для вершин, відповідних X = 0 і X = 1.
22.5 Числове значення i-го субідентіфікатора (при 2 <= i <= N) совпадает счисловым значением (i+1)-го компонента идентификатора объекта.
Останні два байта в пакеті - 0x05 і 0x00. які спільно вказують на значення NULL. Це тому, що ми не можемо мати відповідь в запиті!
Відповідний пакет з 44 байт