eralde

Приложите, пожалуйста, выдачу из WebCLI в ответ на вот такой POST-запрос: { "show": { "ip": { "hotspot": { "chart": { "attributes": "txspeed,rxspeed,sumspeed", "detail": 0, "items": "<MAC-адреса тех устройств, которые входят в Top 5, через запятую>" } } } } }

Пока непонятно в чем проблема, у меня на двух устройствах, где USB3 идет первым и вторым по счету, все отображается как надо. Поищу конкретно KN-1811, чтобы проверить.

Какое это устройство, какая версия прошивки, в каком режиме устройство работает?

Спасибо за репорт! Поправим.

Спасибо за такой подробный комментарий по недочетам! Это ошибка, кнопка сканирования эфира выводится и для UsbLte, и для UsbQmi, но текущий вариант кода запускает сканирование только на UsbQmi-модемах. Это тоже явно ошибка в коде. Остальные пункты будем смотреть вместе с дизайнером.

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

Это проблема не веб-интерфейса, а моего расширения с темной темой (если отключить темную тему, то проблемы нет). Постараюсь поправить побыстрее.

По удивительному стечению обстоятельств как раз я как раз этим сейчас занимаюсь

@vst please check this out

https://help.keenetic.com/hc/en-us

Не хватает слэша после rci: http://192.168.10.1:81/rci/

Поправили возвращаемые прошивкой данные. Теперь не должно возникнуть ситуации, когда в массиве есть несколько точек с одинаковым значением t=0. Не помню по какой причине не стали писать об этом в Changelog, вероятно, потому что до этого уже писали.

Можно передавать массив команд parse: [ { "parse": "interface WifiMaster0/WifiStation0 down" }, { "parse": "interface WifiMaster0/WifiStation0 authentication wpa-psk 12345678" }, { "parse": "interface WifiMaster0/WifiStation0 ssid ***" }, { "parse": "interface WifiMaster0/WifiStation0 description ***" }, { "parse": "interface WifiMaster0/WifiStation0 up" } ] Можно передать массив объектов: [ { "interface": { "WifiMaster0/WifiStation0": { "up": false } } }, { "interface": { "WifiMaster0/WifiStation0": { "authentication": { "wpa-psk": { "psk": "12345678" } } } } }, { "interface": { "WifiMaster0/WifiStation0": { "ssid": "***" } } }, { "interface": { "WifiMaster0/WifiStation0": { "description": "***" } } }, { "interface": { "WifiMaster0/WifiStation0": { "up": true } } } ]

Работа над страницей с настройками приложений идёт. Насколько я понимаю, компонент с новым веб-интерфейсом пока будет доступен только в драфтах. В одном из будущих драфтов карточка "Приложения" на дашборде будет исправлена.

У меня это на тестовом устройстве воспроизвести не получается. Вы не могли бы чуть подробнее расписать, что и в какой последовательности приводит к такому результату?

Насколько я знаю, никто ничего с этим не делал Если проблема возникнет снова -- посмотрим внимательнее.

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

Я скопировал из вашего self-test кусок настроек, который относится к DNS, и залил на своё рабочее устройство: веб-интерфейс работает вполне штатно. WAN-интерфейсы у меня другого типа, но это не имеет значения. Если в браузере нажать F12 и в открывшейся панели перейти на вкладку Console/Консоль, есть ли там какие-нибудь ошибки (в тот момент, когда у вас открыта страница с DNS-профилями)?

Для отладки нужен либо self-test, либо (лучше) удаленный доступ к веб-интерфейсу по SSTP. Достаточно readonly-доступа.

В последнем драфте должно быть исправлено. Не попало в changelog, потому что мы заметили и исправили это раньше вашего сообщения.

Прямо сейчас работу страницы можно исправить, установив компонент ssh. В следующем драфте будет работать и без него.

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

Да, все варианты ручной настройки мы предусмотреть не можем. Если веб-интерфейс не может распознать "тип" подключения корректно, он будет считать, что это VPN-подключение. Мы решили, что для VPN-подключения предупреждение нужно только в том случае, когда оно является в настоящий момент шлюзом по умолчанию в политике по умолчанию. Именно поэтому работает и вариант с максимальным приритетом WireGuard, и настройка, при которой "ручной" IPoE имеет максимальный приоритет.

Нужен файл конфигурации или self-test с вашего устройства. Если оба подключения настроены через веб-интерфейс, предупреждение должно отображаться для обоих.

Хорошо, если с доступом не получится, то не могли бы вы выложить startup-config или self-test?