eralde

Возможно. startup-config скачивается по ссылке http://my.keenetic.net/ci/startup-config.txt С загрузкой этого файла на роутер все несколько сложнее: 1. нужно отправить на роутер вот такой запрос: POST http://my.keenetic.net/rci/ { "put": { "filename": "flash:startup-config", "size":<размер файла в байтах> } } в ответ вы получите что-то вроде { "put": { "port": { "direction": "in", "port": "52633" }, "continued": true } } отсюда нужно достать значение port (в данном случае 52633) 2. дальше нужно отправить ещё один POST-запрос: POST http://my.keenetic.net/fui/ Content-Type: multipart/form-data; port: <значение port из запроса к put> Filedata: <объект типа File, полученный из вашего startup-config> Почитать про File можно тут: https://developer.mozilla.org/ru/docs/Web/API/File 3. после этого нужно дать роутеру команду перезагрузиться POST http://my.keenetic.net/rci/ { "system": { "reboot": {} } } Все запросы к /rci/ подразумевают, что вы отправляете JSON и указываете в заголовках Content-Type: application/json.

@Kirill G приложите, пожалуйста, файл self-test скрытым сообщением

Это возможно, нужно отправить вот такой HTTP-запрос: POST http://my.keenetic.net/rci/ Content-Type: application/json [ { "eula": { "accept": {} } }, { "easyconfig": { "disable": true } }, { "system": { "configuration": { "save": true } } } ] Разумеется, вместо my.keenetic.net можно указать IPv4-адрес (например, http://192.168.1.1/rci/)

@TopGear78 да, действительно, дело в том, что перенести существующие имена вида *.keenetic.link теперь не получится. Можно зарегистрировать новые в доменах netcraze. https://keenetic.ru/ru/service-update Хотя текст со скриншота, конечно, довольно неявно указывает, что перенос работать не будет. Думаю, что мы этот текст подправим.

Пока нет, насколько я знаю. Спасибо, что напомнили

Приложите self-test скрытым сообщением, пожалуйста.

@Ari100krat @mrGhotius @FLK, спасибо за репорт! Будет исправлено в одной из следующих версий

@spatiumstas исходная идея была в том, чтобы при клике по "Изменить" веб-интерфейс переходил на вкладку с настройками сегмента и подсвечивал поле с выбором расписания работы. Видимо, что-то поломалось

Объяснение понятное Но так действительно задумано, потому что в тех полях, где отображается курсор как в поле для ввода текста, действительно можно вводить текст, чтобы отфильтровать список опций и выбрать нужную: Screen Recording 2025-04-11 at 22.03.20.mov

@ava-by веб-интерфейс показывает буквально то, что возвращает ему прошивка. КПД 100% Я информацию о том, что такое происходит специалистам, отвечающим за Wi-Fi передал. Ожидайте, пожалуйста, исправления)

Ошибка в веб-интерфейсе, она будет исправлена в будущих версиях. Настроить то, что для WISP называется On Demand, можно на любом интерфейсе через CLI (interface {name} standby ...). В веб-интерфейс эта настройка вынесена только для WISP и сотовых модемов, потому что для таких интерфейсов хорошо понятно, зачем это может быть нужно. Остальная часть про безопасность, потребление электричества и прочее мне лично кажется довольно странным сценарием использования. Технически, наверное реализуемо. Но уже прямо сейчас вы можете сделать себе "рубильник" для интернета через скрипты в OPKG, управляемый через браузер, телеграм-бота или другие привычные программные средства. В любом случае, на этом форуме мы придерживаемся (стараемся придерживаться) такого правила, что везде, кроме Курилки, в одной теме обсуждается один конкретный вопрос. Если вы считаете, что ваш вариант "Internet-on-demand" -- это полезная и нужная функция, создайте, пожалуйста, отдельную тему про это в разделе Развитие.

@Axl Проблема понятна, можно вашу текущую конфигурацию поправить так, чтобы веб-интерфейс её дальше нормально обрабатывал: - откройте, пожалуйста, WebCLI в веб-интерфейсе роутера (my.keenetic.net/a) - введите все команды из списка ниже по очереди на вкладке Parse, после ввода каждой нажимайте кнопку "Отправить запрос" no schedule rebootrouter no schedule scheduleNaN schedule schedule0 description "Reboot router" action start 58 4 * action stop 59 4 * exit schedule schedule1 description "Интернет (Ночь)" action stop 0 1 * action start 0 8 * exit system reboot schedule schedule0 system configuration save - дальше можно попробовать посоздавать через веб-интерфейс расписания и убедиться, что это нормально работает

Стало намного понятнее, спасибо! Ваши файлы скрытым сообщением я тоже вижу. Подождите, пожалуйста, пока сбрасывать роутер. Веб-интерфейс, похоже, некорректно обрабатывает вашу конфигурацию, не думаю, что сброс поможет. Прямо сейчас можно попробовать вот что: - удалить через CLI расписание, которое вы там создали (или вообще все уж созданные: no schedule {name}) + сохранить конфигурацию (system configuration save) - создать несколько расписаний через веб-интерфейс (это должно нормально сработать) - создать через CLI доп. расписание заново (думаю, что оно и в этом случае пока будет отображаться в веб-интерфейсе без названия)

Выложите self-test или startup-config скрытым сообщением, пожалуйста.

Расписаний можно создать много (точно больше двух). Создание расписаний через веб-интерфейс не должно стирать расписания, созданные через CLI. Опишите, пожалуйста, пошагово, что вы делаете в веб-интерфейсе, что ожидаете получить и что происходит на самом деле. И приложите, пожалуйста, self-test или startup-config отдельно скрытым сообщением (лучше всего тот, где ещё ничего не затерто).

Продолжать запрашивать список статей БЗ, если пользователь решил их не смотреть, конечно, большого смысла не имеет. Это хорошее замечание, спасибо Но вот, чтобы устройству прям "поплохело" от такого... С текущим API, на самом деле, вообще не очень понятно, что будет возвращаться в ответ на запросы из первой попытки, если запросить список статей из базы знаний ещё раз (создав, вторую попытку). Со стороны пользователя API (веб-интерфейса) понять для какой попытки будут приходить данные нельзя, потому что все запросы -- это GET rci/webhelp/v2/ui-notes без дополнительных параметров. Я бы сказал, что каждое открытие всплывающей подсказки приводит к тому, что: - фоновый процесс "опроси базу знаний" в прошивке перезапускается - его статус опрашивается чаще (в веб-интерфейсе остаются опрашивающие "хвосты" от предыдущих попыток) Думаю, что браузер в лимит допустимых запросов в единицу времени упрется быстрее, чем устройству действительно поплохеет, даже в случае 7628

Спасибо за репорт! Меню с настройками в мобильной версии нужно, конечно, скрывать

Спасибо за репорт! Проблема воспроизводится, будет исправлена

Выглядит как лишняя граница, которая не нужна. Спасибо за репорт! Уберем

Есть подозрение, что это "само исправилось" при переделке диалогов

Как вы верно заметили, данные кэшируются. Список компонентов веб-интерфейс запрашивает через команду components list. Команда отправляет запрос от Кинетика на сервер, где с прошивками. Последний ответ на запрос к серверу кэшируется на стороне Кинетика. Попробуйте увеличить время жизни кэша, используя команду components validity-period. Список компонентов запрашивается и на других страницах интерфейса (например, на дашборде), т.е. у большинства людей в кэше ответ для этой команды будет лежать практически сразу. Безусловно, есть сценарий "заблокировал доступ к серверу обновлений отключил Кинетику Интернет -> открыл браузер -> зашел на страницу Приложения", в котором приходится ждать, пока запрос к серверу отвалится по таймауту, но он, на мой взгляд, является достаточно редким. Улучшить можно, подумаем. Пока предлагаю поиграть с настройкой validity-period.

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

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

Будет очень здорово, если вы добавите пару скриншотов для сравнения "было"/"стало"

@yvazik я удалил self-test из вашего сообщения. Ваш селф-тест загружен отдельным сообщением, скрыт и доступен теперь только модерaторам. Публикация селф-теста в открытом доступе может быть небезопасна, поэтому обязательно скрывайте такие сообщения (три точки в верхнем правом углу -> скрыть).