+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблемы с SNMP в версии 5.x

Проблемы с SNMP в версии 5.x, RouterOS

AdunSG

Guest

15.10.2012 14:07:00

Привет! После обновления до 5.x у меня возникли проблемы с SNMP-запросами к PPPoE-сессиям. Моя программа проверяет OID сессии, чтобы узнать, подключен клиент или нет (я использую SharpSnmpLib в своей программе). SNMP-пакеты как будто повреждены, но это происходит только в 50% случаев. В остальных случаях всё работает нормально. Проблемы начались после обновления с 4.x до 5.x. Это происходит в версиях 5.14, 5.17, 5.18 и 5.21. Я нашел несколько обсуждений на эту тему, но ни одно из них не помогло. Надеюсь, вы сможете помочь. Заранее спасибо!

Саймон

Редактирование: ок, я проанализировал SNMP-пакеты с помощью Wireshark. Каждый пакет, который казался поврежденным, содержал один байт больше между командой GetRequest и requestID. В нормальном пакете GetRequest отображался как 02 04, в “поврежденных” — как 02 05 ff. Из-за лишнего байта пакет не может быть обработан. Это ошибка?

AdunSG

Guest

11.01.2013 11:16:00

Наш клиент сообщает, что возникла проблема с декодированием целых чисел. И, разумеется, никаких ошибок SNMP мы не видим, потому что для получения ошибки SNMP нужно, чтобы пакет был расшифрован, а, как я уже говорил, это невозможно. Было бы здорово, если бы вы сказали своему программисту, который написал SNMP-агент, то, что я писал 9 января в 17:24. Это точная формулировка проблемы!

AdunSG Guest	#3 0 16.01.2013 15:59:00 Вверх!

sergejs Guest	#4 0 09.01.2013 13:36:00 Пожалуйста, убедитесь, что проблема не связана с вашей программой SNMP. Запустите snmpwalk с любой машины под Unix (Linux и т.д.). Получаете ли вы какой-нибудь вывод?

AdunSG

Guest

09.01.2013 15:24:00

Привет, спасибо за ответ. Проблема в snmp-walk ^^ Я решил проблему с request-id. Она возникает, если request id слишком большой, например: “52 ed 5d 40” (hex). Такой id работает нормально, а вот “91 56 78 6b” вызывает проблему, потому что: 91 (hex) = 1001 0001. Первый бит равен 1, из-за чего ОС думает, что это отрицательное целое число. И непонятно почему теперь запрос обрабатывается с новым request id: “ff 91 57 78 6b”, содержащим 40 бит. Но стандарты SNMP требуют, чтобы это было 32-битное целое число, поэтому мой клиент не может его обработать из-за дополнительного байта в пакете. Всё работало отлично с версией 4.x. Вы меняли ли кодировки целых чисел? Спасибо, Саймон.

sergejs Guest	#6 0 10.01.2013 14:05:00 Пожалуйста, напишите здесь точные команды, которые не работают должным образом в v5.22.

AdunSG Guest	#7 0 10.01.2013 18:40:00 Привет, у нас возникла проблема с командой SNMP "get-next-request". Скажи, если хочешь посмотреть дамп WireShark. С уважением, Саймон.

sergejs Guest	#8 0 11.01.2013 08:34:00 Пожалуйста, напишите здесь точные команды, которые не работают должным образом в v5.22, и включите в них ошибки, которые вы получили при использовании snmpwalk.

sergejs

Guest

17.01.2013 09:47:00

SNMP v1 requestID — целое число (1 - 2147483647), и если ты отправляешь число больше этого, которое получится отрицательным, ты нарушаешь RFC. SNMP v2 requestID — Integer32 (-2147483648 - 2147483647), кодируется с использованием кодировки BER в форме дополнительного кода двух единиц, и если число отрицательное, к нему нужно добавлять префикс ff, который удаляется при декодировании.

AdunSG

Guest

#10

17.01.2013 11:43:00

Привет, спасибо за ответ. Похоже, мне придётся менять исходный код snmp-клиента, который я использую, чтобы исправить этот «баг» на стороне клиента. Но я немного в замешательстве из-за двух вещей: я думал, целочисленное кодирование соответствует стандартам X.690? (Что вы нарушаете). Почему эта проблема никогда не возникала в версиях 4.x? Я был бы благодарен за ссылку на стандарты, которые вы используете. Это очень помогло бы при изменении клиента. С уважением, Саймон.

sergejs Guest	#11 0 17.01.2013 12:16:00 SNMP в MikroTik разработан в соответствии с RFC, стандартами: RFC 1157, RFC 3414, RFC 3416. http://wiki.mikrotik.com/wiki/SNMP

AdunSG Guest	#12 0 21.01.2013 14:45:00 Привет, спасибо. Я до сих пор не понимаю, где найти то место, где говорится, что нужно добавлять FF. RFC говорит, что нужно использовать ASN.1, который говорит: 10.4.6 Минимальное кодирование двоичного целого числа со знаком по схеме 2’s-complement имеет ширину поля, кратную восьми бит, и также удовлетворяет условию, что старшие девять бит поля не должны быть все нулями и не должны быть все единицами. Если добавить FF к отрицательному целому числу, то первые девять бит будут все единицами. Что нарушит это условие, так что, я думаю, вы используете другой стандарт. Я действительно не могу найти эту часть про FF. Есть ли еще какие-то исключения, которые мне нужно обрабатывать, кроме тех, что с FF для отрицательных целых чисел? Мне действительно стоит проверить дальнейшие отклонения между моим клиентом и вашими агентами кодирования/декодирования, прежде чем лезть в исходный код клиентов. С уважением, Саймон.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры