dimon27254

@KoneTaH @admin @hlnw Если в роутере имеются object-group fqdn, то при выгрузке self-test для каждой группы в логе появляются ошибки вида: Xml::Document: system failed [0xcffd078c], invalid ELEMENT node name: "_NDM_OGDN_4@default/do-122843c3". Xml::Document: system failed [0xcffd078c], invalid ELEMENT node name: "_NDM_OGDN_6@default/do-c81e5440". Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @admin @hlnw Если обратиться к RCI с некорректным или уже удаленным токеном, то в логах появляются сообщения о попытках бана системой 127.0.0.1: Netfilter::Lockout::Manager: "Http": system failed [0xcffd037b], [H4] invalid address '127.0.0.1'. Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @admin @hlnw В 5.2 Alpha 1 модуль ядра xt_multiport.ko теперь не представлен в виде файла, из-за чего "ломаются" скрипты, явно проверяющие его наличие. Он теперь вкомпилирован в ядро, т.к. его можно использовать в iptables без предварительной подгрузки. Это какая-то ошибка, или же запланированное изменение? Проверял на KN-1012.

@eralde @Anna_ @Test Pilot Сейчас информация по созданному токену появляется только после закрытия окна создания. bandicam 2026-07-18 07-40-08-825.mp4 Было бы удобно, чтобы вся информация появлялась сразу же после генерации токена без ожидания закрытия окна. Так можно скопировать токен, оставить его на некоторое время показываться в окне еще для тестов, и в этот момент где-то проверить его корректность, увидев время последнего использования. Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @admin @hlnw В 5.2 Alpha 1 перестали приниматься запросы на localhost:79, для них всегда возвращается ошибка 403, даже с токеном. При этом, 127.0.0.1:79 работает: Проверял на KN-1012.

@eralde @Anna_ @Test Pilot В 5.2 потерялся отступ после группы селекторов: Для сравнения вариант из 5.1.1: Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @Infy @hlnw Имеется контроллер MWS KN-1012, на котором стоит 5.2 Alpha 1, и подключенный к нему ретранслятор NAP-650 с установленной 5.1.1. Время от времени в логах NAP-650 появляются "ack SB length (231) is invalid". 5.1.1 не понимает какие-то сообщения от контроллера на 5.2?

@KoneTaH @admin @hlnw В 5.2 появились токены доступа, которые, как я понимаю, в будущем станут одним единственным способом обращения к RCI из Entware. Хотелось бы понять: 1. Как долго еще останется неавторизованный доступ к RCI по 127.0.0.1:79? На данный момент запросы без токена еще принимаются, хоть система и отправляет в лог предупреждения. 2. Как для пользователя или скриптов в Entware будет выглядеть переход на токены доступа в 127.0.0.1:79? После очередного обновления RCI будет просто возвращать HTTP-код 401 вместо успешной обработки запроса, или же как-то иначе? 3. Хотелось бы увидеть все возможные примеры применения токенов. Судя по всему, они будут полезны не только при обращении к 127.0.0.1:79, но и в каких-то иных сценариях. 4. Всегда ли токен, генерируемый пользователем, будет содержать 56 символов, а также латинские буквы и/или цифры? 5. Возможно ли будет создавать токены с readonly-доступом к RCI? 6. Планируется ли "прикрывать" ndmc -c ? На данный момент там никаких ограничений нет, и система каких-либо предупреждений не возвращает.

Одной замены URL недостаточно, нужно еще править парсинг списков подсетей. Опишу правки для версии 1.10.3. В geo.sh: 1. Замените строку под номером 52 следующим содержимым: curl --connect-timeout 30 --retry 5 --retry-delay 10 --max-time 60 -fsS "https://www.iwik.org/ipcountry/${country}.cidr" -o "$curl_temp_file_path" 2>/tmp/ascn_curl1_error 2. Строку 83 замените на: grep -oE '[0-9]{1,3}(\.[0-9]{1,3}){3}(/[0-9]{1,2})?' "$curl_temp_file_path" 2>"/tmp/ascn_jq_error" >"$geo_subnets_file" У себя протестировал, списки успешно загружаются. Если загрузка завершится ошибкой по какой-то причине, Антискан, как и ранее, скачает с зеркала список RIPEstat. На будущее подумаю о возможности более гибкого указания URL для использования ваших собственных списков 🙂

На данный момент смена источника геоданных не предусмотрена. Могу вам предложить только вариант с правкой исходного кода Антискана.

Не совсем понятен ваш вопрос. Для обновления можно воспользоваться той же командой, что и для установки. Установщик автоматически обновит Антискан до актуальной версии.

@eralde @Anna_ @Test Pilot Импортируем конфиг Wireguard, подсеть которого пересекается с уже имеющимися туннелями. Веб-интерфейс показывает предупреждение: Если нажать кнопку "Отменить", то импорт ожидаемо отменяется. Однако, затем появляется ложное уведомление об успешном сохранении настроек: Вероятно, здесь лучше вообще ничего не показывать, или же какое-то сообщение вида "Импорт отменен". Проверял на NC-1812 с 5.1.0.

@eralde @Anna_ @Test Pilot Во всплывающей подсказке отсутствует пробел между названием сегмента и диапазоном Wi-Fi: bandicam 2026-07-02 22-02-53-418.mp4 В веб-интерфейсе отображается "Гости (5 ГГц)", а в подсказке "Гости(5 ГГц)". Проверял на NC-1812 с 5.1.0.

@eralde @Anna_ @Test Pilot В 5.1 у списка появилась едва заметная заливка, которая отличается от цвета фона: В 5.0.12 она отсутствует: Проверял на NC-1812 с 5.1.0.

Оставлять Антискан в "работающем" состоянии в процессе обновления не очень корректно. Пользователь может обновиться, например, не с 1.10.2 до 1.10.3, а с 1.5 до 1.10.3. Между такими версиями в коде уже значительная разница, и я не готов гарантировать, что созданные ранее запущенной 1.5 списки и/или правила корректно "подхватятся" свежими версиями без перезапуска. Именно поэтому перед удалением или обновлением Антискан всегда останавливается. При повторной установке и/или обновлении далее запускается механизм миграции, который проверяет соответствие конфига/crontab и других файлов актуальной версии. При необходимости выполняется их изменение, сопровождающееся сообщениями вида "В имеющийся ascn.conf добавлен новый параметр ...". После этого пользователь вручную запускает Антискан, а все файлы готовы к работе на новой версии. На будущее я подумаю об автоматическом старте после обновления. Спасибо за предложение 🙂