Учитывая следующий пример / простой файл snmpd.conf (Net-SNMP 5.7.2 на RHEL 7.4)
rwcommunity private 192.168.56.101
trapsess -Ci --clientaddr = 192.168.56.128 -v 2c -c частный 192.168.56.101:162
при запуске демона SNMP
snmpd -f -Lo -D -C -c data / snmpd_test.conf udp: 192.168.56.128: 161
Получаем '' Start Up '' InformRequest с источником IP 192.56.168.1 вместо ... 128 (снимок WireShark ниже)
![InformRequest with source 1 instead of 128](https://i.stack.imgur.com/hjTc2.png)
Это не удивительно, так как опция -D позволяет нам выводить отладочную информацию о том, что
trace: netsnmp_config_process_memory_list (): read_config.c, 696: read_config: mem: память обработки: clientaddr 192.168.56.128 трассировка: run_config_handler (): read_config.c, 562: 9: read_config: parser: обработчик clientaddr не зарегистрирован в это время
Однако веб-источники сообщают:
snmp.conf
... Это значение также используется snmpd при создании уведомлений.
snmpd.conf
trapsess [SNMPCMD_ARGS] HOST предоставляет более общий механизм для определения пунктов назначения уведомлений. SNMPCMD_ARGS должен быть параметрами командной строки, необходимыми для эквивалентной команды snmptrap (или snmpinform) для отправки желаемого уведомления
Я также читал некоторые старые темы, такие как this
- Однако эта опция хорошо работает с snmptrap
snmptrap -D -Lo -Ci --clientaddr = 192.168.56.128 -M + path_to_my_mibs -v 2c-c частный 192.168.56.101:162 "" .1.3.6.1.4.1.abcdef0 i 0
![correct snmpinform with ip source 128](https://i.stack.imgur.com/HWYH4.png)
- Эта опция также работает, когда помещается в snmp.conf (учтите, что здесь нет 'd'), а затем она применяется к snmpset и snmpget (и, возможно, другим)
Итак, мой вопрос: это ошибка документации, ошибка, неправильное использование стека Net-SNMP?