eralde

Спасибо, за напоминание Исправление запланировано на следующую неделю

Выдача по внутреннему поиску будет со временем, я надеюсь, ещё улучшена. Сортировка текущей выдачи, в целом, на наш взгляд, работает более-менее ожидаемо. Это, конечно, не поиск "по смыслу", но в обоих версиях результаты выдаются более-менее релевантные запросу (IPsec в новом интрфейсе на первом месте, потому что слово "сеть" нашлось дважды -- очень релевантный результат ). Какие строки лишние, подскажите, пожалуйста? Мы наверняка какие-то зависимости упустили в новой реализации. Спасибо, это мы точно поправим!

Это результат использования неподходящего перевода (подходящего не нашлось). Поправим, спасибо! Пункт 1, вероятно, уже исправлен, пункты 2 и 4 поправим

Спасибо! Будем разбираться из чего правильнее полные склеивать данные для веб-интерфейса, чтобы были привязки и к IPv4, и к IPv6. Сейчас веб-интерфейс использует show ip hotspot, где IPv6-адресов нет

В какой-то момент настройки IPv6 для WG обязательно появятся Пока прорабатываем как их правильнее вывести

show interface <id интерфейса модема> например, show interface UsbQmi0

В случае PPTP, SSTP и L2TP/IPsec будет использована политика того сегмента, который выбран в поле "Доступ к сети" (на вашем скриншоте -- HomeLan)

Видимо, кто-то очень креативно перевел надпись на кнопке. По смыслу она должна скрывать приложения, которые не установлены. Собственно, показ всех потенциально доступных приложений нужен, чтобы предложить пользователю функции, о которых он может быть и не знает. Выбранный вариант (показывать все/показывать установленные + число колонок) будет запоминаться для конкретного браузера (в Alpha 12 это пока не работает).

Такая ошибка возникает, если веб-интерфейс пытается опрашивать ресурс, возвращающий список компонентов, и при этом: ещё не был инициирован запрос к серверу обновлений запрос был инициирован, ответ получен, но веб-интерфейс отправил "лишний" GET-запрос, уже получив данные Будем разбираться, спасибо

Слово show в URL не нужно, эта команда работает аналогично components list: сначала нужен POST-запрос, затем периодические GET-запросы до ответа с данными

Спасибо! Можно и весь лог скрытым сообщением сюда, если вам так удобнее.

Нужно больше подробностей: - устройство - версия прошивки - как именно настраиваете доступ (поможет скриншот диалога с настройками, например) - есть ли ошибки в логе после сохранения настроек

Попробуйте так: show interface WifiMaster0/AccessPoint0 show interface WifiMaster1/AccessPoint0

Система поддерживает до 64 DNS на каждый интерфейс всего. Ограничим этим значением Потому что обязательно придет пользователь, который захочет на 3, а 5-8-10 и придется обрабатывать этот случай как-то неявно

Запрашивайте components list (<IP_или_доменное_имя_Кинетика>/rci/components/list). Эта команда запускает фоновый процесс, запрашивающий данные у сервера обновлений, поэтому первым отправляете POST-запрос, а дальше опрашиваете тот же URL GETом, пока не получите в ответе что-то кроме {"continued": true}. В финальном JSON с набором компонентов будет что-то такое: Если версии отличаются, значит обновление есть (на моем скриншоте данные для случая, когда обновления нет). В первом POST-запросе можно передать (необязательный) параметр sandbox -- канал обновления прошивки (stable/preview/drаft), тогда вернутся данные для запрошенного канала. Без параметра вернутся данные для выбранного на устройстве канала обновления.

Спасибо за репорт! Это баг, мы о нем знаем, но он пока не исправлен.

Спасибо, это тоже, вероятно, из-за изменений в API

@agentOleg @KYTECHNGAMING @AndreBA спасибо! Ошибки, связанные с MDID и загрузкой страницы настроек Wi-Fi-системы будут исправлены в следующем драфте.

Дело, видимо, в новом способе подгрузки иконок, которыми пользуется веб-интерфейс. Подумаем, что можно с этим сделать.

Выложите, пожалуйста, скрытым сообщением: - startup-config после того, как вы настроили новый сегмент с Captive Portal, но до перезагрузки устройства - self-test после того, как устройство перезагрузилось и сегмент пропал Оба файла можно скачать на странице "Общие настройки системы":

@dimon27254 мне пока на своем устройстве проблему воспроизвести не удалось. Если подождать подольше в вашем случае, то карточка всё равно не грузится?

Спасибо, эту проблему я смог воспроизвести. Расскажите, пожалуйста, подробнее, как вы настраиваете сегмент с Captive Portal? С ним, на первый взгляд, всё нормально

Просто, как вам правильно написали выше, вариант с ручным редактированием settings.json не предусмотрен, поэтому если выполнить то же самое, что делает веб-интерфейс, через CLI вручную, файл тоже перезапишется. Это как раз предусмотренный вариант, будет хорошо, если вам он подойдет.

Здравствуйте, что вы имеете в виду, когда говорите "фильтрация по IP и подключению не работает"? Какие данные и где в интерфейсе вы фильтруете?

Если отключить торрент-клиент не из веб-интерфейса, то настройка сохраняется? Для торрент-клиента можно назначить политику доступа в интернет (создать политику можно через веб-интерфейс, назначить её торрент-клиенту -- только через CLI/WebCLI): (config)> ip policy test Network::PolicyTable: Created policy "test". (config-policy)> permit global ISP Network::PolicyTable: "test": set permission to use GigabitEthernet1. (config-policy)> exit Core::Configurator: Done. (config)> torrent directory - set download directory peer-port - set peer port policy - set network policy for torrent reset - reset daemon settings rpc-port - set RPC port (config)> torrent pol policy - set network policy for torrent (config)> torrent policy test Torrent::Client: Policy test applied. https://help.keenetic.com/hc/ru/articles/360010644660-Как-изменить-профиль-доступа-выхода-в-Интернет-для-torrent-клиента-Transmission Если вы хотите использовать несколько подключений вместе, то имеет смысл включить эту настройку для назначенной политики: https://help.keenetic.com/hc/ru/articles/7490633500572-Многопутевая-передача-суммирование-пропускной-способности-нескольких-интернет-соединений