eralde

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

Добавьте текущее значение 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, после этого маршрут должен появиться в интерфейсе.

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

Спасибо! Пока похоже на то, что веб-интерфейс работает корректно. Может быть у вас установлено мобильное приложение Keenetic и SMS оказываются "прочитаны" через него?

Если вручную подменить ответ системы на такой, где есть непрочитанные SMS, то отображается и счетчик, и иконка в главном меню: В отладке проблемы поможет выдача браузера по адресу http://<IP_Кинетика>/rci/sms/list?interface=<id_интерфейса_модема> (e.g. http://192.168.1.1/rci/sms/list?interface=UsbQmi0) после получения SMS. Стоит учесть, что при переходе к переписке с конкретным абонентом все непрочитанные SMS от него помечаются как прочитанные.

В этом случае все работает ровно так, как нарисовал дизайнер. Цвет фона сознательно выбран таким (таким же, как и фон во всплывающих оповещениях об ошибках, если я правильно помню).

@spatiumstas спасибо за диагностику! Проблема в строчке PersistentKeepalive = 0, придется доработать парсер, чтобы он такие значения отбрасывал.

Если выбрать вариант "Настройка IPv4: Не используется", то никакого статуса не будет вообще. В выбранной вами конфигурации интерфейс, к которому относится этот блок с настройками IPv4, не получает адреса по DHCP. Поэтому и выводится сообщение о том, что (этим интерфейсом) IPv4-адрес не получен. Такая реализация веб-интерфейса, хоть и отличается, от того, что было раньше, является вполне корректной. Статус блока IPv4 выводится только рядом с этим блоком и есть понятный способ, как этот статус скрыть, если IPv4 реально работает поверх иного интерфейса (PPTP/L2TP/PPPoE).

Счетчик отображается только в том случае, когда есть непрочитанные SMS. SMS на скриншоте ещё не прочитано?

Новый -- это тот, который реализован сейчас

Разумеется открыта, я считаю, что новый вариант гораздо лучше предыдущего.

Какой файл конфигурации импортируется? Какие при этом ошибке в логе?

Это не ошибка, а выбранный нами вариант реализации. Все поля, которые невалидны, выделяются таким образом.

Будет добавлено, но не в ближайшей бете точно.