Окно SM-01: Access denied при попытке записи настроек

[san]

При попытке записи настроек в плату SM-01, плата выдаёт предупреждение "Ошибка записи: .4.7.1.6.0: Access denied" и настройки не записываются, хотя у пользователя Администратор есть все три права Ch,Sv,Sm и я не вижу причин для запрета доступа.

r2021

[alx]

По результатам проверок кода swd и его веб-интерфейса могу сказать следующее.

1. При записи в плату SM-01 swd ограничивает лишь запись некоторых значений (< 5) в переменную .6.0 и только для тех, у кого нет права "Sm". В описанном же случае и право Sm было, и OID переменной совсем другой.

2. OID ".4.7.1.6.0", указанный в сообщении об ошибке, означает "переменная .1.6.0 платы, находящейся в слоте 7 блока". В описании тикета сказано, что запись выполнялась в плату SM-01, однако в плате SM-01 нет переменной с OID .1.6.0! В этом нетрудно убедиться, например, запросив MIB платы.

3. Соответственно, в коде веб-интерфейса нет записи в переменную .1.6.0 (а если бы и была, пользователь должен был бы получить ошибку "Not found", так как переменной с таким OID нет в MIB платы. При записи конфигурации в плату SM-01 выполняется запись только в переменные .5.0 и .6.0.

Учитывая изложенные выше факты, я тоже не вижу никаких причин и возможностей для swd запрещать запись в указанную переменную. Предполагаю, что сообщение об ошибке записи в переменную .1.6.0, которое в конечном итоге было отображено в веб-интерфейсе, по неизвестным мне причинам вернула сама плата SM-01 в ответ на запрос записи переменных .5.0 и .6.0. (при том что запись переменной .1.6.0 не запрашивалась). Других возможностей получения данного сообщения я не вижу.

Предлагаю для подтверждения (или опровержения) данного предположения воспроизвести проблему при работе swd с максимальным отладочным выводом (с -l6), после чего проанализировать лог на предмет того, какое сообщение записи было отправлено в плату, и какой был получен на него ответ..

[san]

Напомни пожалуйста как изменить swd отладочный вывод на -l6.

p.s. Проблема воспроизводится в двух блоках, в третьем не воспроизводится. ПО в блоках одинаковое.

[alx]

Replying to san:

Напомни пожалуйста как изменить swd отладочный вывод на -l6.

Надо добавить ему аргумент "-l6". Это, в свою очередь, можно сделать, установив значение переменной ARGS в файле /etc/init.d/swd.sh.

[alx]

Лог-файл после воспроизведения проблемы прикрепи сюда для последующего анализа.

[alx]

Получил по почте логи записи в плату SM-01 конфигурации с получением сообщения об ошибке. Вот что в них:

Jul  8 06:38:46 sw01 daemon.info swd[2902]: admin from [192.168.0.7]: writing variable(s) to slot 16
Jul  8 06:38:46 sw01 daemon.debug swd[2902]: slot 16: sending 64 bytes: 01 35 05 00 04 37 00 aa 00 00 00 00 13 13 00 00 00 00 00 13 00 13 01 00 00 00 01 00 00 00 00 00
Jul  8 06:38:46 sw01 daemon.debug swd[2902]: slot 16:                   00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 13 00 00 00 00 00 00 00 00 01 00 01 06 00 00 00
Jul  8 06:38:46 sw01 daemon.debug swd[2902]: slot 16: 9 bytes received: 81 35 05 00 00 01 06 00 02
Jul  8 06:38:46 sw01 daemon.debug swd[2902]: Sending response: {"cmd":"snmpset","result":{".4.16.1.6.0":"Access denied",".4.16.5.0":"OK",".4.16.6.0":"Not found"}}

Как видно из этого фрагмента, плате SM-01 в слоте 16 передается сообщение с запросом записи переменных .5.0 и .6.0:

На этот запрос плата SW-01 отвечает сообщением о результате записи двух переменных:

Однако, как я и предполагал ранее, по неизвестной причине плата SM-01 в своем ответе вместо сообщения о результате записи переменной .6.0, которая запрашивалась, сообщает о результате записи переменной .1.6.0, и при этом поле статуса имеет значение 2, что означает "ошибка доступа".

В результате полученного от платы SM-01 ответа веб-интерфейс и отобразил сообщение об ошибке записи переменной .1.6.0.

Аналогично ведет себя другая плата:

Jul  8 06:39:03 sw01 daemon.info swd[2902]: admin from [192.168.0.7]: writing variable(s) to slot 7
Jul  8 06:39:03 sw01 daemon.debug swd[2902]: slot 07: sending 64 bytes: 01 45 05 00 04 37 00 aa 00 00 01 00 13 0f 04 01 00 00 00 02 00 00 01 00 00 00 01 00 00 00 00 00
Jul  8 06:39:03 sw01 daemon.debug swd[2902]: slot 07:                   00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 40 0f 00 00 00 00 00 00 01 01 00 00 01 06 00 00 00
Jul  8 06:39:03 sw01 daemon.debug swd[2902]: slot 07: 9 bytes received: 81 45 05 00 00 01 06 00 02
Jul  8 06:39:03 sw01 daemon.debug swd[2902]: Sending response: {"cmd":"snmpset","result":{".4.7.1.6.0":"Access denied",".4.7.5.0":"OK",".4.7.6.0":"Not found"}}

Вот повтор эксперимента с первой платой:

Jul  8 06:50:33 sw01 daemon.info swd[2902]: admin from [192.168.0.7]: writing variable(s) to slot 16
Jul  8 06:50:33 sw01 daemon.debug swd[2902]: slot 16: sending 64 bytes: 01 75 05 00 04 37 00 aa 00 00 00 00 13 13 00 00 00 00 00 13 00 13 01 00 00 00 01 00 00 00 00 00
Jul  8 06:50:33 sw01 daemon.debug swd[2902]: slot 16:                   00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 13 00 00 00 00 00 00 00 00 01 00 01 06 00 00 00
Jul  8 06:50:33 sw01 daemon.debug swd[2902]: slot 16: 9 bytes received: 81 75 05 00 00 01 06 00 02
Jul  8 06:50:33 sw01 daemon.debug swd[2902]: Sending response: {"cmd":"snmpset","result":{".4.16.1.6.0":"Access denied",".4.16.5.0":"OK",".4.16.6.0":"Not found"}}

Вывод: проблема в поведении плат SM-01, возвращающих неожиданный ответ на запрос записи конфигурации. Демон swd и веб-интерфейс ведут себя корректно в соответствии с полученным от платы ответом. Рекомендую обратиться к разработчику платы SM-01.

[san]

Алексей, скажи пожалуйста что означает последний байт в данных переменной .5.0

[san]

Алексей сообщил. что это маска аварии НРП.
Теперь я могу уточнить условия воспроизведения бага на SM-01:
Если установить чекбокс "маска аварии НРП" - всегда воспроизводится, при этом сама настройка маски успешно записывается, а 0 в переменную .6.0 судя по всему не записывается.