_dreamer_

Новичок
  • Публикаций

    6
  • Зарегистрирован

  • Посещение

Информация о _dreamer_

  • Звание
    Абитуриент
  • День рождения
  1. Ага, оно! Добра тебе и спасибо опять таки. Остается отыскать концы .iso.org.dod.internet.private.enterprises.33826
  2. kylinich, посмотрел. Спасибо тебе, добрый человек. Но! Есть такой файл: http://forums.devx.com/attachment.php?attachmentid=1161&d=1151477615 В нем после ...enterprises.nscrtvRoot.nscrtvHFCemsTree описано начало еще 14-ти веток. Полное описание трех из них - PROPERTY, ALARMS, COMMON - 1, 2 и 3 соответственно, есть в тех файлах, которые ты дал. Но эти же ветки, да еще 11-ая вдобавок - некая oaIdent (Amplifiers), да еще с какими-то description'ами есть тут: http://www.circitor.fr/Mibs/Mib/N/NSCRTV-ROOT.mib Вот за FIBERNODE (10-ая ветка, fnIdent) отдельное спасибо, респект и уважуха. Пригодится... Но нужна 9-ая ветка, dorIdent (DownStream). :-( Ну и продолжаю искать ...enterprises.33826 . Пока одной рукой писал, другой наткнулся на http://en.pudn.com/downloads71/sourcecode/database/detail258790_en.html Там судя по описанию вроде как есть все, или почти все что нужно. Позже пробую зарегаться и скачать...
  3. Добрый день. Ищу mib-файлы, в которых описываются следующие ветви: 1. .iso.org.dod.internet.private.enterprises.17409.1.9 Для ветвей ...enterprises.17409.1.(1, 2, 3, 11) нашел, а вот для 9 обыскался. 2. .iso.org.dod.internet.private.enterprises.33826 Тут вообще все сложно. В оптическом приемнике RTM OR862-I использованы oid'ы из этих ветвей, но в инете нашлось далеко не все, а производитель молчит чего-то. Если есть у кого и не жалко - откликнитесь-поделитесь, плиз...
  4. Значит есть устройство, которое отправляет трапы как положено. Тогда тем более предлагаю исходя из всего вышесказанного считать описываемое поведение SNR-ERD-3.2 пусть мелким и незначительным (хотя кому как), но багом или недоработкой. Поэтому предлагаю: 1. Подумайте, может все таки стоит (если есть такая возможность) обратить внимание руководства на этот вопрос? Ведь это хорошо, когда админ (читай покупатель) будет сам решать, с каким community должны отправляться трапы. Это не только хорошо, но и правильно, в конце концов. Не думаю, что исправление займет много времени, или что это очень уж сложно. 2. Ладно, пусть требуется значительное количество заинтересованных, чтобы что-то там изменить в планах, и взяться за исправление этого бага. Не организовать ли тогда опрос, чтобы тема была на виду у всех? Что касается SNR-ERD-Pro-mini... Как я понял, где-то в загашнике у нас отыскалось достаточно много завалявшихся без дела SNR-ERD-3.2. Поэтому возиться мне придется именно с ними. У нас никто покупать SNR-ERD-Pro-mini не будет, тем более, что они почти на 700 р дороже, чем SNR-ERD-3.2 при достаточно похожем функционале. Отличия в этих устройствах для нас несущественны.
  5. Какая интересная фича! Не вижу никакого смысла в такой защите... В устройствах SNR-ERD-3.2 (которое, как Вы конечно знаете, использует snmp v1) строка community не только является своего рода паролем, но и передается в открытом (незашифрованном) виде во всех пакетах, таких как get, set, next, response и trap. Согласитесь, при этом считать описанное в п.1 первого поста поведение устройства "защитой" можно только с натяжкой и оговоркой в том плане, что мол после настройки и монтажа от устройства никто ничего не должен хотеть (на него не отправляют set, get, next), и поэтому оно никому не отвечает (response), а только лишь отправляет трапы (да, не содержащие community доступа), и все. Но необходимость в таком поведении, думаю, если и бывает, то редко. Чаще от устройства кто-то чего-то время от времени хочет, и оно что-то отвечает, ну или делает. При этом, повторюсь, строка community передается, причем передается открытой. И если уж некий злоумышленник проник в сеть и сумел перехватить трап (как я понял, Вы говорите именно о таком случае), то скорее всего он сумеет перехватить и другие пакеты [ от | для ] этого устройства. Тогда узнать community и получить полный доступ к устройству просто, как два байта переслать. Думаю, всем будет гораздо удобнее, если в трапах будет отправляться именно то community, которе нужно админу, суть заказчику, а не разработчику устройства. Так что позволю себе не согласиться с Вами в том, что это не баг, и прошу помощи. P.S. Вот если бы дополнительно к "главному" community можно было бы менять по своему усмотрению и community в трапах, это была бы хоть и не очень нужная, но фича.
  6. Начал работать с устройством SNR-ERD-3.2, прошивка firmware_SNR-ERD-3.4.hex. Первые грабли уже нашел. 1. community отправляемых устройством трапов - 'trap', а не то, которое установил я. Пример: -------------------------------------------------------------------------------- username@my_host:tcpdump | grep 192.168.X.Y замыкаю-размыкаю alarm 1 на GND и вижу 14:41:21.498740 vlan NN, p 0, IP 192.168.X.Y.snmp-trap > my_host.snmp-trap: C=trap Trap(79) E:40418.2.3 192.168.X.Y enterpriseSpecific s=2 65793 [|snmp] 14:41:21.494301 vlan NN, p 0, IP 192.168.X.Y.snmp-trap > my_host.snmp-trap: C=trap Trap(77) E:40418.2.3 192.168.X.Y enterpriseSpecific s=3 65793 [|snmp] -------------------------------------------------------------------------------- Видим, что C=trap. Что это - баг или фича? Ведь с других устройств (коммутаторы, UPS'ы) трапы приходят с community, заданным админом, т.е. там C=нужное_слово. Очень хочется, чтобы community в трапах с SNR'ки было то, которое нужно мне. Это важно... Как быть? 2. NET-SNMP версии 5.4.2.1 (как другие - не знаю, не проверял) не может нормально работать с MIB, взятой как и прошивка, с этого же форума. Пример: -------------------------------------------------------------------------------- username@my_host:snmptranslate -On -Td SNR-ERD-3::temperatureSensorRelease No log handling enabled - turning on stderr logging Expected "(" (_): At line 272 in /usr/share/snmp/mibs/SNR-ERD-3.txt Should be ACCESS (SetON): At line 272 in /usr/share/snmp/mibs/SNR-ERD-3.txt Bad parse of OBJECT-TYPE: At line 272 in /usr/share/snmp/mibs/SNR-ERD-3.txt SNR-ERD-3::temperatureSensorRelease: Unknown Object Identifier -------------------------------------------------------------------------------- Открываем MIB и в этом месте (line 272) видим: """ remoteControlContact8 OBJECT-TYPE SYNTAX INTEGER { termostat_set_ON (3), switch (4), manual_set_ON (2), man_off (1), man_on (0), auto_off (6), auto_on (5) } MAX-ACCESS read-write STATUS current DESCRIPTION "qwerty" ::= { resetsSet 3 } """ Как оказалось, snmptranslate ругался на строки, содержащие символ '_'. Тот же пример после правки (удаления этого символа во всем файле, точнее, в 12 строках) текста MIB: -------------------------------------------------------------------------------- username@my_host:snmptranslate -On -Td SNR-ERD-3-MIB::temperatureSensorRelease .1.3.6.1.4.1.40418.2.3.0.1 temperatureSensorRelease OBJECT-TYPE -- FROM SNR-ERD-3-MIB DESCRIPTION "Check the text of message" ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) snr(40418) snr-erd(2) snr-erd-3(3) erd3TrapGroup(0) 1 } -------------------------------------------------------------------------------- Красота, да и только! Кто-нибудь еще наблюдал подобные проблемы? Конечно, можно было бы использовать цифровую запись OID'ов и не мучаться с snmptranslate, да и поправить скачанный файл вроде ничего не стоило, но осадочек остался. Думаю есть смысл пофиксить это в новом MIB'е. У кого проблем не было - тем все равно, а тем у кого были - приятно. Делов-то на несколько минут. Вот.