snmp varbind conversation bug

[SKYnv]

@victor said in snmp varbind conversation bug:

А можно получить дамп пакетов с трапами? И как сконфигурен сам трап в NetXMS?

дамп во вложении и пример настройки трэпа тоже, я по всякому пробовал, и прописыванием oid varbind'а. Последняя попытка была позициями указать, однако все равно такая вот канитель. Результат одинаковый во всех случаях.

---

traps.pcapng

[SKYnv]

удалось воспроизвести?

[victor]

Воспроизвести на моих устройствах не удалось. Теперь собираюсь попробовать прямо в ишодниках подсунуть пакеты из дампа - тогда по идее должно повториться.

[SKYnv]

@victor said in snmp varbind conversation bug:

Воспроизвести на моих устройствах не удалось. Теперь собираюсь попробовать прямо в ишодниках подсунуть пакеты из дампа - тогда по идее должно повториться.

беда с длинными строками что ли? Завтра буду менять железо на котором крутиться и ось апгредйить если повториться то отпишусь.
Будет FreeBSD 9.0 x64 плюс заместо mysql будет Percona (хотя одно и тоже по сути), в виртуалке все запускалось без проблем. Есть мысль еще обновить порт для freebsd по наличии свободного времени, но с этим до 1.2.4 подожду наверно.

[victor]

Попробовал у себя - все работает как надо:

[01-Nov-2012 21:38:52] SNMPTrapReceiver: looking for SNMP security context for node 192.168.64.1 HP6440B
[01-Nov-2012 21:38:52] SNMPTrapReceiver: received PDU of type 4
[01-Nov-2012 21:38:52] Received SNMP TRAP .1.3.6.1.4.1.171.11.63.6.2.20.0.2 from 192.168.64.1
[01-Nov-2012 21:38:52] SNMPTrapReceiver: looking for SNMP security context for node 192.168.64.1 HP6440B
[01-Nov-2012 21:38:52] EVENT 500 (ID:7983 F:0x0001 S:0 TAG:"") FROM HP6440B: SNMP trap received: .1.3.6.1.4.1.171.11.63.6.2.20.0.2 (Parameters: .1.3.6.1.2.1.1.3.0 == '5550541'; .1.3.6.1.6.3.1.1.4.1.0 == '.1.3.6.1.4.1.171.11.63.6.2.20.0.2'; .1.3.6.1.4.1.171.11.63.6.2.20.2.1 == '02 B8 70 F4 8D 20 AB 00 07 00 ')

Похоже жто проблема возникает не при обработке пакета, а при получении значения в качестве текстовой строки. Наскольку я помню, у вас UNICODE сборка сервера? Тогда возможно проблема в настройках CodePage. Если он стоит в UTF-8 скажем, то iconv (библиотека конвертации, которую использует сервер) скорее всего воспримет строку как некорректно сформированную, и прекратит конвертацию, оставив в буфере мусор.

[SKYnv]

@victor said in snmp varbind conversation bug:

Попробовал у себя - все работает как надо:

[01-Nov-2012 21:38:52] SNMPTrapReceiver: looking for SNMP security context for node 192.168.64.1 HP6440B
[01-Nov-2012 21:38:52] SNMPTrapReceiver: received PDU of type 4
[01-Nov-2012 21:38:52] Received SNMP TRAP .1.3.6.1.4.1.171.11.63.6.2.20.0.2 from 192.168.64.1
[01-Nov-2012 21:38:52] SNMPTrapReceiver: looking for SNMP security context for node 192.168.64.1 HP6440B
[01-Nov-2012 21:38:52] EVENT 500 (ID:7983 F:0x0001 S:0 TAG:"") FROM HP6440B: SNMP trap received: .1.3.6.1.4.1.171.11.63.6.2.20.0.2 (Parameters: .1.3.6.1.2.1.1.3.0 == '5550541'; .1.3.6.1.6.3.1.1.4.1.0 == '.1.3.6.1.4.1.171.11.63.6.2.20.0.2'; .1.3.6.1.4.1.171.11.63.6.2.20.2.1 == '02 B8 70 F4 8D 20 AB 00 07 00 ')

Похоже жто проблема возникает не при обработке пакета, а при получении значения в качестве текстовой строки. Наскольку я помню, у вас UNICODE сборка сервера? Тогда возможно проблема в настройках CodePage. Если он стоит в UTF-8 скажем, то iconv (библиотека конвертации, которую использует сервер) скорее всего воспримет строку как некорректно сформированную, и прекратит конвертацию, оставив в буфере мусор.

да unicode, а как бороться? или удостовериться?

[victor]

Главное что стоит в параметре CodePage в netxmsd.conf. Там не должно быть UTF-8.

[SKYnv]

@victor said in snmp varbind conversation bug:

Главное что стоит в параметре CodePage в netxmsd.conf. Там не должно быть UTF-8.

не помогает Виктор.

Пробовал с пустым CodePage
и с ISO8859-1

в первом случае варбинды пусты.
во втором нечитаемые символы, а именно 023f703f3f3f3f

С момента теста поменялась операционка на которой крутится сервер и версия сервера
freebsd 8.3x32 >> freebsd 9.0x64
netxms 1.2.3.1 >> netxms 1.2.4

Возможно ли как-нибудь локализовать проблему?

Виктор поправка.
Включил AllowTrapVarbindsConversion=1 и варбинд развернулся нормально
[Normal]  N_Industrialnaya_14_str11  MAC notification. (01 B8 70 F4 8D 86 AB 00 15 00 )
Тогда еще вопрос, данную строку я могу обработать скриптом? чтобы выделить мак, порт, состояние. В каком месте тогда это лучше проделать? в самом ивенте по <my_script(%2)> ?

---

[victor]

Если надо выделить часть этого значения и вставить в текст сообщения в событии, то наверное да, самое правильное место будет вызывать скрипт через макрос в тексте. Только это будет %[script] (квадратные скобки, не угловые).

[SKYnv]

@victor said in snmp varbind conversation bug:

Если надо выделить часть этого значения и вставить в текст сообщения в событии, то наверное да, самое правильное место будет вызывать скрипт через макрос в тексте. Только это будет %[script] (квадратные скобки, не угловые).

да, угловые это атрибуты. так а передача пармаетра?

%[my_script(%3)]
и

sub main(s)
{
return s;
}

Возвращают пустую строку.
хотя
%[my_script]
и

sub main()
{
return "my string";
}

Отрабатывает нормально.

есть какой-то секрет с передачей параметра?

[victor]

В скрипты, вызываемые через %[], параметры передать нельзя. Но скрипт, вызванный таким образом, получает те-же переменные, что и скрипт в Event Processing Policy - $node, $event, и параметры события в $1, $2, и т.д.