eralde

Сейчас, если нажать на название приложения на дашборде, то веб-интерфейс редиректит текущую вкладку на страницу "Приложения" и открывает диалог. Обычные HTML-ссылки можно открывать в фоновой вкладке (средней кнопкой мыши, например, или через Cmd + клик в macOS). Наверное, интерфейсом будет чуть удобнее пользоваться, если ссылки в нем тоже будут так работать (сейчас так точно работают не все ссылки)

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

В некоторых местах в веб-интерфейсе можно выбрать один или несколько сетевых интерфейсов (например, Connect via). Если у двух интерфейсов совпадают описания, то, чтобы всегда было понятно, что именно человек выбирает, к описанию дописывается тип интерфейса. "Мигание" связано с тем, что мы обновляем описания либо сразу у всех сетевых интерфейсов (и с вашим конфигом происходит коллизия, слово "Сегмент" появляется), либо только у части (например, только у сегментов; коллизии не происходит, слово "Сегмент" пропадает).

Слово "Сегмент" появляется и исчезает, потому что у одного из портов задано точно такое же описание (IoT). Подумаем, что с этим можно сделать

Понять, что происходит, поможет полный конфиг устройства, например. Или self-test.

Спасибо за репорт! Мы это заметили сегодня и поправили, но в Beta 3 исправление уже не попало. В Beta 4 порты в UPnP будут отображаться нормально.

Недосмотрели, придется вернуться к этому вопросу ещё раз. Спасибо!

Что значит "время от времени"? Это воспроизводится только на смартфоне? Что отдает браузер, если запросить http://root.local/assets/language/locale.en.json?

То, что ретрансляторы не занимаются маршрутизацией трафика

Такого не было

@Le ecureuil

Ну нужно писать про все найденные баги веб-интерфейса в одной теме. Потом невозможно найти, что уже было замечено/исправлено, а что -- нет. Кроме того:

Добавьте текущее значение comment в запрос: curl -kfsS "http://192.168.80.50/rci/interface?name=wg0" --header "Content-Type: application/json" -X POST --data-raw '[{"wireguard":{"peer":[{"key":"bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=", "comment": "my-comment", "client-id": "1450150"}]}}]'

Нет, конечно. Создавайте тему в Развитии, с объяснением того, зачем вам такая конфигурация. Ещё можно писать в техподдержку, они тоже считают "голоса" по каждому такому вопросу. Веб-интерфейс запрограммирован на работу с определенным подмножеством всех возможных конфигураций Кинетика. Это подмножество -- то, что можно настроить через сам веб-интерфейс (не считая, WebCLI, конечно). Чтобы это подмножество расширить, нужен достаточно массовый запрос от пользователей. Кроме этого, нужно учитывать сложность реализации. В разговоре про дополнительные точки доступа в сегменте мне лично, например, не очень понятно, как будет выглядеть блок настрек Wi-Fi сегмента, если такую функцию добавить.

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

Тут придется действовать по аналогии. Можно настроить нужный кусок через CLI/WebCLI, потом прочитать GET-запросом нужный кусок конфигурации (тоже через WebCLI или открыть ссылку вида <IP>/rci/... в браузере) и ориентироваться на тот формат, который выдаст браузер.

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

Нужно завернуть всё ещё в один address:

Вот такие варианты работают: ➜ curl -X POST http://192.168.24.1/rci/interface/Wireguard2/ipv6 \ -H "Content-Type: application/json" \ -d '{"address":[{"address": "2001::34"}]}' { "address": [ { "status": [ { "status": "message", "code": "39387236", "ident": "Network::Interface::Ip6", "message": "\"Wireguard2\": added static address 2001::34." } ] } ] } ➜ curl -X POST http://192.168.24.1/rci/interface/Wireguard2/ipv6 \ -H "Content-Type: application/json" \ -d '{"address":{"address": "2001::34"}}' { "address": { "status": [ { "status": "message", "code": "39387236", "ident": "Network::Interface::Ip6", "message": "\"Wireguard2\": added static address 2001::34." } ] } } Можно ориентироваться на то, что отправляет веб-интерфейс для других подключений, где настраивается IPv6

А что в отправили в качестве данных POST-запроса? Если Wireguard2 существует и авторизация не требуется (у пользователя admin нет пароля), то вроде такой вариант работает, да: Если нужна авторизация, то вернется код 401, не 400: Это curl на компьютере, не на самом Кинетике, но разницы быть не должно

Идея в том, насколько я помню, что таким образом мы агитируем пользователя включить хоть какую-нибудь фильтрацию DNS. Возможно, в текущих реалиях это уже лишено большого смысла.

Через интерфейс, боюсь, что никак. Скриптом, аналогичным скрипту @Garret Sky можно, нужно только дописать префикс no к командам для соответствующих маршрутов.

@Dim McAlastair, @vasek00, @AskuSU придется подождать до следующей сборки. Исправление готово, но, по нашему недосмотру, не попало в Beta 2. Пока заставить список устройств работать можно, только выбрав для фильтрации DNS один из доступных в веб-интерфейсе вариантов (или через CLI выполнить dns-proxy filter engine public/skydns/nextdns (или no engine)).

Вы все делаете правильно. Попробуйте вызвать после вашей команды system configuration save, после этого маршрут должен появиться в интерфейсе.

Вы хотите добавлять маршруты файлом или по одному? Добавить один маршрут несколько проще.