Хорошо. Мы можем сказать следующее:
- Запросы у обоих менеджеров идентичны
- Ответы на оба запроса идентичны
Это означает, что либо выход Net-SNMP "искажен" / преобразован, либо выход EasySNMP равен.
К сожалению, захваты пакетов не показывают взаимодействия, которые были описаны в оригинальной версии поста, поэтому мы не можем сразу сказать, какой менеджер виноват. Тем не менее, можно сделать вычет на основе значений, которые мы видим.
Вывод вашего Python-скрипта является почти расширенным набором выводов snmpwalk:
Net-SNMP:
- AC 84 C6 5F 95 EF B0 4E 26 8B 1C C5 C0 4A 00 AE
Скрипт Python:
- C2 AC C2 84 C3 86 5F C2 95 C3 AF C2 B0 4E 26 C2 8B 1C C3 85 C3 80 4A 00 C2 AE 59 C2 93 C2 B0 4E 26 C2 8B 4E C2 AD
Так почему же были добавлены дополнительные байты, и почему некоторые байты были потеряны? Это пахнет как перекодировка исходных данных, верно?
Мы можем заметить, что байт C2 много всплывает. Что это такое? Это «расширенный ASCII» (на самом деле такого нет, но во многих кодовых страницах) для персонажа. Ага, красный флаг. Почему это красный флаг? Потому что это обычно свидетельствует о неверной интерпретации UTF-8 . (Я мог бы объяснить более подробно , почему это так, но я позволю вам исследовать кодировки Unicode отдельно, если хотите.)
Итак, используя онлайн-инструмент или two , давайте декодируем этот второй поток байтов как UTF-8 и посмотрим, какие логические кодовые точки мы получаем:
U + AC U + 84 U + C6 U + 5F U + 95 U + EF U + B0 U + 4E U + 26 U + 8B U + 1C U + C5 U + C0 U + 4A U + AE U + 59 U + 93 U + B0 U + 4E U + 26 U + 8B U + 4E U + AD
Эй, это выглядит знакомо! (Опять же, я выделил биты, соответствующие выходу Net-SNMP.) U + 00 отсутствует (предположительно, потому что , что является "нулевым" байтом, как в ASCII ), и все еще есть куча шум в конце (если вам интересно, они отображаются так: "& # x59; & # x93; & # xB0; & # x4E; & # x26; & # x8B; & # x4E; & # xAD; "), но теперь мы можем хотя бы посмотреть, что происходит: ваш исходный поток байтов был перекодирован в виде строки UTF-8. Действительно, Кодировка Python 3 по умолчанию - UTF-8 .
Причина, по которой байты типа C6 полностью исчезли, заключается в том, что они выходят за пределы диапазона ASCII, поэтому отображение «нечисто» в Unicode. Оказывается, ASCII C6, - это U + 00C6, который представлен в UTF-8 C3 86 , так что теперь мы знаем, откуда берутся несжатые байты.
Итак, EasySNMP обрабатывает ваш результат обхода как строку , а не как непрозрачную последовательность байтов, и в результате Python искажает его. Затем, когда вы написали .encode("hex"), вы получили представление шестнадцатеричной пары этой новой фальсифицированной строки UTF-8.
Это, вероятно, не должно происходить. Ответ SNMP четко обозначен как «OctetString», и спецификация говорит нам, что «Тип OCTET STRING представляет произвольные двоичные или текстовые данные» . MIB (который вы, по-видимому, не используете или, по крайней мере, не предоставил) для агента, с которым вы общаетесь, может предоставить дополнительную информацию о кодировании; в отсутствие этой информации невозможно точно узнать, как должен отображаться OCTET STRING. Например, эта ошибка Net-SNMP обсуждает буквально создание догадки , когда это применимо.
В любом случае, все очень интересно, но что мы можем с этим поделать?
Документы EasySNMP довольно тонкие, но мы можем немного покопаться в исходном коде (и в процессе обнаружим, что EasySNMP на самом деле является просто оболочкой Python для Net-SNMP! ) и включен список проблем EasySNMP, где выясняется, что кто-то жаловался на это до .
Опять же, что мы можем с этим поделать?
Хм, я не уверен, что мы многое можем сделать с этим. В настоящее время это недостаток EasySNMP. Вещи Unicodised (либо самим EasySNMP, путем преобразования в строки Python, либо описанным выше модулем Compat Net-SNMP), даже если они не должны быть.
Однако, этот глава предложил обходной путь , который вы можете попробовать:
session = Session(
hostname='192.168.10.150',
community='public',
version=2,
use_sprint_value=False
)
Этот новый последний аргумент должен отключить преобразование значения. Однако я не уверен, потому что по документам это уже False по умолчанию.
Помимо попыток сделать это в любом случае, я думаю, что вам лучше всего добавить свой вес в соответствующий отчет (ы) о проблеме и оказать давление на разработчика, чтобы он предложил исправление. К сожалению.