SNMP не собираются данные

[MaG]

какую ещё инфу предоставить? могу дать мибы и доступ к железке

[victor]

Доступ к железке получить было бы очень полезно. Пишите мне на майл - victor-at-netxms.org.

[victor]

Спасибо за доступ! Проблема в том, что это устройство не возвращает sysObjectId (.1.3.6.1.2.1.1.2.0), хотя по стандарту все должны его возвращать, а NetXMS пытается этот OID читать для оперделения того, есть SNMP на хосте или нет. Я добавил sysDescr (.1.3.6.1.2.1.1.1.0) как альтернативный тестовый OID, теперь устройство определяется как поддерживающее SNMP, и позволяет собирать данные. Я могу прислать патч для сервера или новый бинарник, если надо.

[MaG]

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

[victor]

Надо заменить файлы node.cpp и snmp.cpp в каталоге src/server/core на приложенные.

---

node.cpp

snmp.cpp

[wizarom]

подниму эту тему, чтоб не плодить похожих.

Пытаюсь подключить по SNMP коробку под управлением dd-wrt. Диагностика приводит к следующей ситуации:

rain@rub-s-mon:~$ snmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.2.0
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
rain@rub-s-mon:~$ snmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips
rain@rub-s-mon:~$ nxsnmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.2.0
Request timed out
rain@rub-s-mon:~$

Подскажите, где чего еще смотреть? что не так?

[victor]

Похоже на баг в нашей SNMP библиотеке. Вы могли бы получить tcpdump'ом полные пакеты, отсылаемые и получаемые snmpget и nxsnmpget?

[wizarom]

@victor said in SNMP не собираются данные:

Похоже на баг в нашей SNMP библиотеке. Вы могли бы получить tcpdump'ом полные пакеты, отсылаемые и получаемые snmpget и nxsnmpget?

вот что у меня получилось

snmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips

sudo tcpdump -vvv -s 1514 port 161 and host 192.168.1.1 or 10.10.50.10
00:59:00.616406 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 71)
    10.10.1.13.53215 > 192.168.1.1.snmp: [bad udp cksum 4224!]  { SNMPv2c { GetRequest(28) R=1788996865  system.sysDescr.0 } }
00:59:00.620446 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 134)
    10.10.50.10.snmp > 10.10.1.13.53215: [udp sum ok]  { SNMPv2c { GetResponse(91) R=1788996865  system.sysDescr.0="Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips" } }

при этом ответ почему то идет от 10.10.50.10 - а это адрес интерфейса tun (openvpn) на 192.168.1.1 (поднят туннель 10.10.50.0 между сетями 192.168.1.0/24 и 10.10.1.0/24)
но snmpget этот ответ устраивает...

а в случае с nxsnmpget

nxsnmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.1.0
Request timed out

sudo tcpdump -vvv -s 1514 port 161 and host 192.168.1.1 or 10.10.50.10
01:09:49.119563 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69)
    10.10.1.13.55689 > 192.168.1.1.snmp: [bad udp cksum 9952!]  { SNMPv2c { GetRequest(26) R=24175  system.sysDescr.0 } }
01:09:49.122712 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 132)
    10.10.50.10.snmp > 10.10.1.13.55689: [udp sum ok]  { SNMPv2c { GetResponse(89) R=24175  system.sysDescr.0="Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips" } }

ну и раз теперь все видно то:

nxsnmpget -c public -v 2c 10.10.50.10 .1.3.6.1.2.1.1.1.0
.1.3.6.1.2.1.1.1.0 [STRING]: Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips

то есть если опросить по адресу используемом для openvpn-туннеля, все ок.

как быть?

[pipyta]

как по мне, то тут нет ничего удивительного, что пакет не может к Вам вернуться через IP ethX ибо смысла в  этом нет.  Маршрутизатор смаршрутизировал ваши пакеты по своей таблице, а вот на клиенте уже своя таблица маршрутов поэтому  и такие расхождения.
 Сам столкнулся с похожей проблемой. Можно попробовать поиграться с iptables , но я смысла особого не видел городить огород и просто использовал Ip тунелей, благо у меня  там статический openvpn.

[victor]

Моя рекомендация вообщем-то такая-же: использовать IP адрес туннеля как primary host name. Странно что snmpget принимает ответы с другого IP - технически понятно как это сделать, но это поперек всех стандартов. Если IP адрес туннеля динамический, то можно использовать DNS имя.

[wizarom]

понятно, что совсем не по стандартам. будем использовать адреса туннелей.
спасибо за помощь!