__group__ ticket summary component type owner reporter status created _changetime _description _reporter 1 очередь 269 Непрохождение пакетов больше определенного размера sw баг alx alx reopened 2017-09-08T18:57:42+05:00 2025-11-11T18:05:27+05:00 "После сетевого шторма, связанного с образованием колец, плата SW-01 пришла в странное состояние, когда нельзя было подключиться по SSH или открыть страницу по HTTP. Исследование показало, что короткие пакеты проходят нормально, а более длинные - нет. Так, `ping -s200 xxxx` работал, а `ping -s300 xxxx` - нет. Судя по выводу tcpdump'а, явление было симметричным: длинные пакеты не проходили как извне к процессору платы SW-01, так и от процессора платы во внешнюю сеть. Вот попытка подключиться по ssh: {{{ 18:15:59.625897 IP 192.168.0.75.56615 > 192.168.1.58.22: Flags [S], seq 2755932079, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 757640138 ecr 0], length 0 18:15:59.626351 IP 192.168.1.58.22 > 192.168.0.75.56615: Flags [S.], seq 137816485, ack 2755932080, win 14480, options [mss 1460,sackOK,TS val 28558387 ecr 757640138,nop,wscale 3], length 0 18:15:59.626394 IP 192.168.0.75.56615 > 192.168.1.58.22: Flags [.], ack 1, win 1040, options [nop,nop,TS val 757640138 ecr 28558387], length 0 18:15:59.627374 IP 192.168.0.75.56615 > 192.168.1.58.22: Flags [P.], seq 1:39, ack 1, win 1040, options [nop,nop,TS val 757640139 ecr 28558387], length 38 18:15:59.627770 IP 192.168.1.58.22 > 192.168.0.75.56615: Flags [.], ack 39, win 1810, options [nop,nop,TS val 28558388 ecr 757640139], length 0 (далее, видимо, плата что-то нам отправляла, но мы ничего не получали) }}} Вот попытка запроса по HTTP: {{{ 18:17:00.475280 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [S], seq 1347444039, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 757700987 ecr 0], length 0 18:17:00.475718 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [S.], seq 1981456750, ack 1347444040, win 14480, options [mss 1460,sackOK,TS val 28618808 ecr 757700987,nop,wscale 3], length 0 18:17:00.475758 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, options [nop,nop,TS val 757700988 ecr 28618808], length 0 18:17:00.475897 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757700988 ecr 28618808], length 301 18:17:00.706245 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757701218 ecr 28618808], length 301 18:17:00.965583 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757701478 ecr 28618808], length 301 18:17:01.288082 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757701800 ecr 28618808], length 301 18:17:01.733221 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757702245 ecr 28618808], length 301 18:17:02.414970 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757702927 ecr 28618808], length 301 18:17:03.576607 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757704089 ecr 28618808], length 301 18:17:05.700559 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757706213 ecr 28618808], length 301 18:17:09.743590 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757710256 ecr 28618808], length 301 18:17:10.476651 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0 18:17:10.477041 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28628739 ecr 757700988], length 0 18:17:17.626537 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757718139 ecr 28628739], length 301 18:17:20.476590 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0 18:17:20.476938 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28638668 ecr 757700988], length 0 18:17:30.476657 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0 18:17:30.476941 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28648598 ecr 757700988], length 0 18:17:33.193606 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757733706 ecr 28648598], length 301 18:17:40.481933 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0 18:17:40.482262 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28658533 ecr 757700988], length 0 }}} Значения FrameSizeLimit в регистрах 0x0a80xx00 коммутатора были правильные. Перезапись регистров командой `/etc/init.d/dxsetup start` не помогла. Рестарт swd не помог. Помог софт-ресет коммутатора командой `phyctl writedx 0x00000058 0x00ff4003`, причем в процессе этого ресета не инициализировались ни таблицы, ни регистры. Сразу после записи в регистр 0x00000058 большие пакеты начали проходить." alx 1 очередь 188 Требуется измеритель уровня сигнала в TDM маппере ПЛИС (sw) улучшение alx san assigned 2016-08-04T14:38:34+05:00 2025-10-15T18:00:07+05:00 "~~Отдельная ячейка коммутационного поля TDM маппера, скомутировав в неё нужный канал мы должны увидеть уровень сигнала в этом канале.~~ На вкладке ""Данные TDM"", кроме hex и bin добавить ещё переключатель ""уровень dBm"", при переключении на этот вариант в ячейках должен отображаться уровень сигнала принятого коммутатором от платы." san 1 очередь 304 "Резервирование потоков: изменить алгоритм варианта ""без возврата на основной""" ПЛИС (sw) улучшение alx san assigned 2017-11-03T13:33:39+05:00 2025-10-18T14:19:19+05:00 "Сценарий: Пользователь настроил резервирование ""без возврата на основной"". 1. ОСН-норма, РЕЗ-норма. Данные идут по потоку ОСН 2. ОСН-авария, РЕЗ-норма. Данные переключаются на поток РЕЗ 3. ОСН-норма, РЕЗ-норма. Данные по прежнему идут по потоку РЕЗ 4. ОСН-норма, РЕЗ-авария. Данные переключаются на поток ОСН 5. ОСН-норма, РЕЗ-норма. Данные переключаются на поток РЕЗ Поведение в пункте 5 кажется пользователям не логичным, и мне в том числе. Раз уж вынуждено было произведено переключение на '''основной''' поток, и он в норме, то какой смысл в возврате на резервный ? Предлагаю: в режиме ""без возврата"" производить переключение на другой поток только при аварии на текущем потоке. " san 1 очередь 537 "Резервирование потоков: добавить опцию ""передавать/не передавать данные в резервном потоке""" ПЛИС (sw) улучшение alx san assigned 2021-09-08T11:59:20+05:00 2025-10-15T18:00:07+05:00 "Сейчас при переходе на резерв одной стороны, эта сторона передаёт на дальнюю сторону извещение, через биты RAI в ЦСС. Сделано это для того, чтобы в резервном потоке можно было передавать другие данные и переключение на обоих сторонах было одновременным(чтобы не получилось так что одна переключилась на резерв, а другая нет и передает ложные данные пользователю). В передаче и анализе RAI есть минус - в случае если ЦСС формируется не в нашем блоке, то в нём может присутствовать RAI, что может привести, как минимум, к ложному переключению на резерв или гипотетически к ""кольцу RAI"" Алексей(ledol) предлагает добавить еще один вариант алгоритма резервирования: Не передавать RAI и в резервном потоке всегда передавать данные из основного, тогда каждая сторона независимо от другой может переключаться на резерв." san 1 очередь 666 Перезапускать платы SM-01, SM-02 и SM-03 при перезапуске swd sw улучшение alx san new 2024-02-13T14:53:13+05:00 2024-02-16T11:49:49+05:00 "При загрузке нового конфиг файла в блок, после перезапуска swd, пользователи думают, что все платы теперь работают в новой конфигурации. Однако платам SM для перехода на новую конфигурацию требуется перезапуск, пользователи часто об этом забывают. Предлагаю после автоматической загруки нового конфига в плату SM у которой уже есть конфиг выдавать пользователю диалог с запросом на перезагрузку платы SM(как это делается когда пользователь сам загружает в плату конфиг нажатием ""Применить""). " san 1 очередь 803 Реализовать новую систему ключей агента Zabbix sw улучшение alx alx new 2026-03-13T17:52:49+05:00 2026-03-19T17:25:58+05:00 "В существующей системе именования ключей агента Zabbix вторым элементом является, как правило, наименование платы. Это создает целый ряд неудобств, в том числе не позволяет в полной мере воспользоваться возможностями современных версий сервера Zabbix. Например, у нас имеется несколько типов плат (SM-01, SM-02, SM-03), у которых практически полностью совпадает MIB. Кроме этого, запланирована разработка плат SM-11 и SM-12, у которых, как я подозреваю, MIB будет таким же. Однако невозможно создать в Zabbix один шаблон для всех этих плат сразу, так как существующая схема требует указания наименования платы в основной части ключа (`MC04.SM-01.snmp.7.5.2.0[...]`), а сервер Zabbix не позволяет использовать макросы в основной части (то есть нельзя написать так: `MC04.{#BOARDNAME}.snmp.7.5.2.0[...]`). Zabbix может использовать макросы только в параметрах ключа (`MC04.SM-02.snmp.7.5.2.0[{#MACRO}, ....]`). Как результат, для каждой из пяти перечисленных плат приходится создавать свой отдельный шаблон, отличающийся только наименованием платы. === Основная часть ключа === Для преодоления этой проблемы предлагается реализовать новую систему именования ключей агента (существующую систему предлагается оставить для совместимости). Новый формат ключа предлагается сделать таким: `MCv2.[]` - ""MCv2"" - префикс, позволяющий отличить новые ключи от старых; - - наименование функции (как и в старой системе, только набор будет сокращен). Таким образом, все существенные части ключа (кроме функции) переносятся в параметры, в основной части остается только наименование выполняемой функции. Например: Было: `MC04.SM-01.snmp.7.5.2.0[12]`, стало: `MCv2.getvar[12, .7.5.2.0, name=SM-01]`. === Формат параметров === Также предлагается кроме позиционных параметров, которые уже были раньше, ввести опциональные именные параметры, имеющие формат `<имя>=<значение>` (см. пример выше). Это позволит легче и проще преобразовывать существующие шаблоны к новому формату ключей, в идеале, одной заменой в текстовом редакторе. Именные параметры предлагается сделать не зависящими от позиции и не влияющими на позиционные аргументы. То есть следующие параметры будут эквивалентны: `[.7.5.2.0, 12, name=SM-01]`, `[.7.5.2.0, name=SM-01, 12]`, `[name=SM-01, .7.5.2.0, 12]`. === Набор функций === Предлагается следующий набор функций ключей: - getvar; - boardlist. ==== getvar ==== Предлагается следующий формат параметров: `[, ]`. Агент возвращает значение переменной с OID платы в слоте . //Именные параметры:// - `name=<наименование платы>`: дополнительно проверяется, что установленная в слоте плата имеет указанное наименование. Если это не так, агент возвращает ошибку. - `type=<код типа платы>`: дополнительно проверяется, что установленная в слоте плата имеет указанный код типа. Если это не так, агент возвращает ошибку. - `format=`: позволяет устранить неоднозначность формата возвращаемого значения. Так как во внутреннем протоколе обмена с платами отсутствует специальный тип ""двоичные данные"", для передачи двоичных данных используется тип ""строка"". Но, во-первых, произвольные двоичные данные не всегда представляют собой валидный код UTF-8, а во-вторых, даже если представляют, работать с таким представлением не очень удобно, т.к. трудно найти среди символов нужный двоичный байт. В запросе API можно было указать параметр `strings2data`, и тогда строки возвращаются в виде массива байт. В агенте Zabbix реализован другой механизм - если в строке есть хотя бы один непечатный символ, байты преобразуются в последовательность 16-ричных кодов, разделенных пробелами (примерно так, как это делает библиотека libsnmp).[[br]][[br]] Проблема в том, что получатель строки не всегда имеет возможность знать, получил ли он преобразованные в hex данные, или данные в таком виде и были отправлены непосредственно платой. Для устранения этой неоднозначности предлагается использовать параметр `format=`, который безусловно преобразует принятую из платы строку в заданный формат (к типам данных, отличным от строки, эти параметры не применяются). Предлагается реализовать следующие значения параметра: - `string` - полученная от платы строка возвращаются в виде строки ""как есть""; - `array` - полученная от платы строка возвращается в виде массива значений байтов, например имя платы SW-01 будет возвращено как `[83,87,45,48,49]`, такой формат удобен для последующей обработки javascript'ом на стороне сервера; - `hex` - полученная от платы строка возвращается в виде строки, состоящей из 16-ричных представлений каждого байта, разделенных пробелами, например имя платы SW-01 будет возвращено как `53 57 2D 30 31`; - `auto` - формат по умолчанию, как это есть сейчас: `hex` если в строке есть хотя бы один ""непечатный"" символ (байт с кодом меньше 32) и `string` в противном случае. Возможно, стоит возвращать hex также в случае невалидного UTF-8 кода? **TODO** еще частой проблемой является отсутствие признака ""знаковости"" возвращаемого платой значения. То есть, например, получив от платы числовое значение, представленное байтами 0xA73C97B2, агент Zabbix не знает, имеется ли в виду значение 2805766066 или -1489201230. Может быть имеет смысл добавлять в ключ дополнительный параметр, который ""подскажет"" агенту Zabbix, знаковое или беззнаковое число ожидается от платы? Можно, конечно, учитывать знак на стороне сервера (предобработкой), но указание в ключе параметра типа `format=signed` могло бы избавить от такой необхоидмости... ==== boardlist ==== Предлагается следующий формат параметров: `[<код типа платы>]`. Если код равен нулю или отсутствует, возвращается список всех плат. Иначе возвращается список плат с указанным кодом типа. //Именные параметры:// - `type=<код типа платы>`: то же самое, что и один позиционный параметр; не уверен, что это необходимо, но можно добавить для удобства. - `name=<наименование платы>`: возвращается список плат с указанным наименованием. ==== nthbyte, hwordat, hwordat-be, wordat, wordat-be ==== Функции `nthbyte`, `hwordat`, `hwordat-be`, `wordat`, `wordat-be` предлагается реализовать предобработкой в зависимых элементах данных на стороне сервера. ==== ethstat, readsfp ==== Функции `ethstat` и `readsfp` предлагается реализовать через `getvar` - то есть добавить плате SW-01 переменную, возвращающую значения счетчиков порта коммутатора (переменная, из которой читаются данные SFP, в плате уже есть). Этим заодно (кроме унификации) устраняется неоднозначность: в ключах MC04.sys.ethstat не указывался номер слота, поэтому, во-первых, можно было получить счетчики только активной платы, а во-вторых, при активации/деактивации резервной платы SW-01 источник данных просто подменялся - вместо счетчиков одного коммутатора начинали отдаваться счетчики совсем другого! Все счетчики порта будут возвращаться в одной переменной в виде JSON массива. " alx 2 очередь 272 "Кнопка ""Применить"" на вкладке Ethernet->VLAN, Ethernet->RSTP" web-интерфейс (sw) улучшение alx san new 2017-09-18T15:22:59+05:00 2023-09-11T17:58:56+05:00 "Предлагается вместо немедленной записи каждого изменения настроек в коммутатор, записывать все изменения только после нажатия кнопки ""Применить"". За время работы аппаратуры разные пользователи жалуются на неудобство ""мгновенного"" применения настроек на вкладке Ethernet->VLAN. Случайно ткнув мышкой парой пикселов правее-левее можно сломать связь с блоком. Кроме этого, ""пошаговая"" настройка немного сложнее, т.к. нужно соблюдать определённую последовательность действий, чтобы не потерять связь с блоком.(например при переносе порта CPU в другой VLAN нужно обязательно сначала создать новый vlan, а потом уже удалять старый) А недавно я сам столкнулся с неудобством такого подхода настраивая VLAN на блоках в кольце RSTP(""промежуточные"" состояния настройки сложно проанализировать, кроме того шаги вызывают кольца и перестроения дерева, и гораздо проще было бы настроить за ""одно применение"" чем пошагово. p.s. Ваня сравнивает настройку VLAN на нашей аппаратуре с игрой [https://ru.wikipedia.org/wiki/Сапёр_(игра) ""Сапёр""]." san 2 очередь 303 Резервирование потоков: добавить настройку таймаута детектирования аварии ПЛИС (sw) улучшение alx san assigned 2017-11-03T13:03:19+05:00 2025-10-15T18:00:07+05:00 Сейчас при возникновении кратковременной аварии поток переключается на резервсразу. В некоторых случаях, например при грозе или э/м помехах пользователи предпочитают чтобы поток не переключался на резерв при кратковременных авариях, поэтому предлагается ввести настройку таймаута. san 2 очередь 314 Добавить поле комментария в настройки групповых каналов web-интерфейс (sw) улучшение alx san new 2017-12-06T18:03:27+05:00 2017-12-06T18:06:08+05:00 "Добавить поле комментария к каждому групповому каналу, в настройки групповых каналов В старый интерфейс и новый. " san 2 очередь 358 Новая функция: дистанционный анализ трафика ethernet sw улучшение alx alx new 2018-10-10T16:22:10+05:00 2018-10-10T18:10:10+05:00 "Иногда при исследовании прохождения (или непрохождения) трафика по сети требуется узнать, что за пакеты ходят через наш коммутатор. Когда блок находится в физической доступности, можно подключить анализатор (компьютер) к свободному порту и миррорить туда интересующий трафик. Но если блок находится далеко и доступен только по сети, это сделать затруднительно. Отчасти задача решается направлением (миррорингом) кадров в порт CPU и наблюдением за трафиком TCPDUMP'ом, но здесь есть ряд недостатков. Во-первых, tcpdump не покажет, каким образом тегированы кадры, так как сразу после приема кадра его тэг отбрасывается. Во-вторых, трафик может быть довольно большой, и CPU в нем может ""захлебнуться"". В-третьих, возможна нежелательная ""интерференция"", например, из-за случайного пересечения адресов (скажем, CPU отвечает на запрос, посчитав, что запрос адресован ему, хотя это был запрос из независимой изолированной сети)... Насколько я помню, в коммутаторе есть такая функция - проба трафика. Суть ее в том, что из потока кадров выбираются отдельные с некоторой вероятностью (например 1 из 100) и отправляются в CPU. Предлагается задействовать ее для наблюдения за трафиком. Кадры, направленные в CPU этой функцией, могут быть опознаны по соответствующему коду (код указывается в тэге). Предлагается такие пакеты направлять в специальный VLAN (снабжать их тэгом с ID, например, 2222). Это исключит ""интерференцию"" с настоящим пользовательским трафиком (мониторинг/управление). В SW-01 для наблюдения за кадрами создать новый интерфейс с VLAN ID 2222. Наблюдать трафик можно будет как tcpdump'ом, так и самим демоном swd, который мог бы принятые кадры отображать (с минимальным анализом) в веб-интерфейсе. Прошу высказывать мнения, пожелания, критику и т.п." alx 2 очередь 814 Заменить fork()+execl() и popen() на posix_spawn() sw улучшение alx alx new 2026-04-10T10:16:01+05:00 2026-04-10T17:57:14+05:00 "В настоящее время для запуска внешних процессов swd выполняет fork(), затем закрывает все файловые дескрипторы (кроме нужных для коммуникации) и затем выполняет execl(). Выполнение fork() - тяжелая операция, так как создается копия ""тяжелого"" процесса swd. Предлагается выполнять внешние процессы с помощью вызова posix_spawn(), который не дублирует память процесса, а блокирует родительский процесс до момента старта образа процесса-потомка. Экспериментально подтверждено, что в условиях значительного объема памяти, используемой родительским процессом, вызов posix_spawn() ведет себя лучше (работает даже когда fork() завершается с ошибкой). Вместо закрытия дескрипторов предлагается устанавливать им флаг CLOEXEC. Аналогичным образом следует заменить вызовы popen(), также использующей fork(). " alx 2 очередь 66 При несконфигурированной ПЛИС выдавать аварию swd баг alx alx new 2014-07-31T16:28:14+06:00 2014-07-31T16:28:14+06:00 "При постоянной ошибке конфигурации ПЛИС (например испорчен файл прошивки) горит зеленая лампочка ""OK"", и о неисправности платы ничего не гвоорит. Надо формировать аварию при незаконфигурированной ПЛИС." alx 2 очередь 310 Мониторинг регенераторов SM-xx web-интерфейс (sw) задача alx san new 2017-11-22T15:33:18+05:00 2018-10-09T10:11:50+05:00 "Пользователи часто жалуются на сложность мониторинга регенераторов подключенных к плате SM-xx. Тема эта уже давно назрела, попытался всё описать, если что-то забыл или наврал поправляйте. Что нужно от регенераторов: I. Собственно мониторинг. Периодическое обновление информации о состоянии участков линейного тракта, накопление статистики и т.д.. II. Детализация аварии на линейном тракте. Допустим тракт состоит из N участков (N-1 регенераторов) и в момент аварии пользователи хотят получить детализированное сообщение в программе мониторинга и логах, на каком участке и на какой паре произошла авария. Сложности текущего варианта: 1. Для мониторинга нужно периодически посылать команду опроса, т.е. программе мониторинга кроме чтения придётся делать ещё и запись в определённую переменную, либо посылать команду другими средствами. В любом случае это дополнительная сложность. 2. При новом опросе таблица очищается и до окончания опроса в таблице не корректные данные (не понятно регенератор пропал(не отвечает) или опрос ещё не завершен) а точного признака окончания опроса нет, есть некоторые критерии, но мы их сами ещё не можем до конца сформулировать и я думаю что перекладывать задачу определения критериев конца опроса на пользователя не правильно. 3. Проблема с отказом EOC канала на платах SM-01, суть: EOC канал может перейти в нерабочее состояние при некоторых условиях(одновременное попадание ЕОС пакетов с разных сторон в регенератор). Подробности у Влада. 4. Конфликты с совместным доступом, это следствие из п. 1-3, если два пользователя независимо друг от друга будут проводить опрос и считывать таблицу, они могут мешать друг-другу. - Очищение таблицы вызванное опросами одного мешает прочитать таблицу другому. - При повторном опросе до завершения предыдущего, возможно проявление проблемы с EOC на SM-01. Так-же это возможно при мониторинге с двух сторон Предлагается: a. Плата SW-01 сама периодически отправляет команды опроса платам SM-xx и кэширует таблицы регенераторов для мониторинга и отображения в веб-интерфейсе. b. При возникновении аварии линейного тракта производится немедленный опрос регенераторов для детализации аварии. с. Пользователь, при необходимости, может через веб-морду нажать кнопку опрос не дожидаясь автоматического обновления таблицы. Вопросы: - Критерии конца опроса (таймаут, кол-во регенераторов,...) - Опрос по разным парам. Для простоты ограничиться опросом по паре А? - Что делать с опросом с двух концов? " san 2 очередь 31 Сделать коммутацию обратного потока Е1 web-интерфейс (sw) улучшение alx alx new 2014-03-21T14:07:03+06:00 2014-06-16T18:13:53+06:00 Сделать коммутацию обратного потока Е1. alx 2 очередь 277 Окно платы SM-xx: опрос при входе web-интерфейс (sw) улучшение alx san new 2017-09-27T17:04:47+05:00 2017-09-28T10:02:00+05:00 "Предлагается при каждом открытии окна платы SM-xx автоматически запускать ""опрос"" чтобы не вводить пользователя в заблуждение устаревшими данными в таблице. p.s. это решение временное, в идеале в таблице должно отображаться актуальное состояние регенераторов, без нажатия кнопок." san 2 очередь 306 Прятать лишние вкладки web-интерфейс (sw) улучшение alx san new 2017-11-16T20:01:51+05:00 2020-04-15T12:03:38+05:00 "Предлагаю дать пользователю возможность скрыть ненужные ему вкладки из окна веб-морды. Например вкладка CDR может быть ненужной, если в блоке нет платы VE, а вкладка Сервис используется обычно только при неполадках и т.д. .. Предлагаю где-нибудь, например на вкладке Разное, разместить набор чекбоксов для выбора нужных/ненужных вкладок. Предлагаю хранить набор выбранных вкладок в ПЗУ блока." san Как-нибудь потом 171 "Реализовать функцию ""всестороннего резервирования""" sw улучшение alx alx new 2016-03-28T17:04:21+05:00 2019-01-11T17:50:22+05:00 "Реализовать функцию ""всестороннего резервирования"" (выбора направления групповых каналов) и формирования констант в незанятые канальные интервалы" alx Как-нибудь потом 273 Функция автоматического контроля канала sw задача alx alx assigned 2017-09-18T18:46:23+05:00 2025-10-15T18:00:07+05:00 "viktam натолкнул меня на идею (см. mc-04:#12). Предположим, в сети организован некий канал, который никак не используется в ""нормальных"" ситуациях, а предусмотрен на случай проведения каких-либо ""аварийных"" работ. Канал, который не находится в работе, легко непреднамеренно ""сломать"" в процессе различных изменений конфигурации, и не заметить этого. Будет очень печально, если на момент наступления таких работ окажется, что аварийный канал не работает. Поэтому требуется регулярная проверка исправности такого канала. Возникла идея - возложить такую проверку на саму аппаратуру. Мне видится несколько возможных вариантов проверки исправности канала (в зависимости от его типа и характера): передача в канал некоего сигнала (гармонического для речевых каналов, цифрового для цифровых) и прием этого сигнала на выходе канала. Периодичность посылки должна настраиваться - раз в час, раз в сутки и т.п. Период должен быть достаточно большим чтобы не мешать нормальному использованию канала. Если приемник не ""увидел"" сигнал в течение двух интервалов (тоже, наверное, можно настраивать), формируется предупреждающее сообщение (придумать как и какое). Сигнал не должен быть очень простым, чтобы не было ложных положительных срабатываний, но и не должен быть слишком сложным, чтобы легко был реализуем средствами ПЛИС. Как вариант, последовательность тональных посылок нескольких определенных частот определенной длительности... Предлагаю обсудить детали возможной реализации и степень полезности этой функции." alx Как-нибудь потом 97 Предложение: хранить в плате sw-01 запасные конфигурации swd задача alx san new 2015-03-17T17:27:17+05:00 2017-11-17T13:29:18+05:00 "При выгрузке конфигурации, кроме носителей подключеных к ПК предусмотреть ещё выгрузку во внутреннюю память sw. Название конфигурации должен задать пользователь(например, это может быть имя файла, или как угодно) ну и соответственно при загрузке конфигурации в блок, дать возможность выбрать и из конфигураций во внутренней памяти" san