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

[victor]

А если nxsnmpget запустить, что он скажет?

[MaG]

root@netxms:/usr/local/netxms/bin# snmpget -v1 -c public 10.255.0.162 .1.3.6.1.4.1.11195.1.5.5.1.4.1
iso.3.6.1.4.1.11195.1.5.5.1.4.1 = INTEGER: -27

root@netxms:/usr/local/netxms/bin# ./nxsnmpget -v1 -c public 10.255.0.162 .1.3.6.1.4.1.11195.1.5.5.1.4.1
.1.3.6.1.4.1.11195.1.5.5.1.4.1 [INTEGER]: -28

работает но показания отличаются

[victor]

Странно. А как выглядит overview для этого хоста в консоли? Там стоит флажок isSNMP?

[MaG]

стоит isSNMP=No
при пуле выдаёт:
[26.02.2013 14:40:20] **** Poll request sent to server ****
[26.02.2013 14:40:20] Poll request accepted
[26.02.2013 14:41:46] Starting configuration poll for node 8marta8
[26.02.2013 14:41:46] Checking node's capabilities...
[26.02.2013 14:41:46]    Checking SNMP...
[26.02.2013 14:42:18] Capability check finished
[26.02.2013 14:42:18] Checking interface configuration...
[26.02.2013 14:42:18] Unable to get interface list from node
[26.02.2013 14:42:18] Interface configuration check finished
[26.02.2013 14:42:18] Checking node name
[26.02.2013 14:42:18] Node name is OK
[26.02.2013 14:42:18] Finished configuration poll for node 8marta8
[26.02.2013 14:42:18] Node configuration was not changed after poll
[26.02.2013 14:42:18] **** Poll completed successfully ****

[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]

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