Ловля необычных SNMP-trap сообщений необычным способом

[Homas]

Из статьи непонятно:
1. Косяк был только с UDP портом на который передавались сообщения, SNMP Trap пакет в остальном был полностью правильным?
2. Настроить порт на который передавался было не возможно? Вы не пытались настроить сервер, чтобы он слушал на другом порту?
3. Производитель предоставляет MIB? Вы пытались разобрать что находится в той самой бинарной части, которую вы просто отрезали (там могла быть дополнительная интересная информация, например: timestamp, ID-порта, его предыдущее состояние и т.д.)?

[ThreeDHead]

1. Пакет приходит в своём формате, а я пожалел своего времени на его анализ. Но там не так много бинарных данных. Текстовые данные дали достаточно необходимой информации.
2. Тоже сперва подумал что можно просто начать слушать еще и на другом порту, но wireshark сказал что там просто raw-data, и я эту идею бросил.
3. Во-первых, эти модели коммутаторов уже достаточно стары. Во-вторых, указанный вендор, по моему мнению, крайне не любит давать нормальных MIB'ов или следить за их актуальностью. Хотя, по SNMP они управляются достаточно сносно.

[Ovsiannikov]

Можете приложить .pcap файл с трапами?
А то даже не верится, что в настолько стандартной штуке можно накосячить.
«сервер никак не хотел их ловить» — каким софтом ловили?

[ThreeDHead]

Пожалуйста, RAW-пакет — mega.co.nz/#!jpkDAaZD!-zbtFsPHHVrlbfmW6wWPsWrr2IRmTPeXoTPy90dbUtg

Но это не косяк, это видимо фича маркетологов вендора.

[ThreeDHead]

Сработает xinetd -loop rate?

[ThreeDHead]

Не факт.

-loop rate: По умолчанию — 10.

И нет, писать демон не проще. А код на PHP и студент сможет модифицировать к меняющимся реалиям.

[ThreeDHead]

Т.е. ты предлагаешь нагрузить несчастную виртуалку инструментами разработчика, заниматься компилированием проекта по каждому чиху — от от малейшего изменения до апгрейда ядра. Какой в этом смысл?

[ThreeDHead]

По сислог. Ты мне напомнил историю с техподдержкой DLink'а, когда у нас DES-7210 окачуривался в ЧНН, от сообщений "%EFHW-4-NEXTHOP_NO_RESOURCE". Сообщения сыпали тысячами в минуту.
Мы очень долго с ними бодались (без малого год), но они ничего решить так и не смогли. Так вот однажды, на очередной вопрос — «Нормально ли что мы получаем в лог столько сообщений?», их специалист ответил что — «Вообще то, для журналирования, нужно использовать сислог-сервер!». Т.е. он предложил еще и сислог задосить, перевалив проблему с больной головы на здоровую.

[ThreeDHead]

Если ты хочешь подробнее про реализацию, то приведенный код — это лишь пример. На боевом сервере всё несколько иначе и скриптов несколько штук, и каждый занимается своей задачей.

[Phoen]

Предполагаю что статья также актуальна и для DGS-1100, как-то был такой в хозяйстве, но желания возиться с велосипедами для приемки трапов, раз уж вендор такой принципиальный, не возникло :) Автору респект.