admin

Да, есть такая фича для провайдеров... если вкратце, она работает так, что роутер автоматически соединяется с их системой мониторинга и удаленного входа в интерфейс. И там есть опция заблокировать доступ к интерфейсу из домашней сети. То есть, роутером могут управлять только сотрудники провайдера удаленно. Эта фича тестировалась с несколькими небольшими провайдерами и распространения пока не получила. Давайте по порядку, Определимся, она ли это. Для этого скажите название провайдера. Фича задумывалась строго для тех случаев, когда провайдер предоставляет свое оборудование, а не портит роутер, приобретенный абонентом. Блокировка доступа к интерфейсу из дома или удаленно — это опция. Её можно не включать. И можно настроить так, что при нажатии кнопки "reset" конфиг сбросится к базовым настройкам, которые заданы провайдером, чтобы подключение не отвалилось. Все, что требуется для подключения к провайдеру, настраивается без упомянутой фичи. Нет таких секретных команд, которые недоступны владельцу роутера. Другое дело, что провайдер не хочет их показывать.

Вам нужно создать обращение в поддержку. Установите более свежую версию 4.1 или 4.2 Beta, к обращению приложите файл диагностики self-test, снятый с роутера после возникновения проблемы (ошибки о том, что не удалось соединиться с сервером).

Состояния интерфейсов внутри системы начиная с версии 4.0 были переработаны. В частности, это выражается в наблюдаемом поведении. Слой "link" находится на более низком уровне, и событие о его переходе в "up" приходит раньше, чем успевает поменяться состояние "connected". Подправьте скрипт, чтобы он реагировал на изменение change=connected. События change=link в Вашем случае можно игнорировать.

Пришлите self-test скрытым сообщением, а то приходится гадать. Если у Вас старая версия KeeneticOS и прямой KeenDNS (белый адрес или вход из домашней сети), то виноват может быть браузер с TLS 1.3 hybridized Kyber. Можете либо отключить в браузере, либо поставить свежую KeeneticOS 4.2 из Dev.

Без какой-либо диагностики и точных данных приходится гадать. Клиент выбирает точку сам. Отключите band-steering, и дальше смотрите на клиенте, что он видит — это будут объективные данные:

Приоритет подключения по кабелю работает с самого первого релиза mws, и в Вашем случае проблема может быть связана с настройками коммутатора. Посмотрите в сторону настроек STP. Проверьте переход ретранслятора на провод, исключив коммутатор по дороге: перенесите ретранслятор к контроллеру и убедитесь, что такой сценарий работает без лишних перезагрузок. Если остались вопросы, лучше обратитесь в поддержку, у них есть готовые инструкции на такие случаи. Нужно будет передать им файл с диагностикой, снятый с устройства.

Диагностику приложите скрытым сообщением. И со стабильной версией лучше в поддержку.

Это объяснимо: при входе в web мы явно спрашиваем о новой версии и зажигаем лампочку. Но само облако не делает вызов в сторону устройства, когда выходят обновления, и никогда не делало. Если в web и приложение не заходить, устройство само обращается за "новостями" довольно редко: либо при получении/смене IP-адреса, либо периодически примерно раз в сутки.

Приложение разработано так, чтобы нормально работать с роутером по Wi-Fi, если он при этом не подключен к интернету. Этот сценарий тестируется. Хотя мы и могли что-то упустить, давайте разберемся. Для начала убедитесь, что Ваш телефон во время проверки не перешел на мобильную сеть. Выключите мобильный интернет на телефоне, для чистоты эксперимента оставьте только Wi-Fi. Также убедитесь, что телефон не подключился к другой Wi-Fi-сети. Если проблема сохраняется, попробуем с Вашей помощью разобраться, дальше объясним как.

Всем за детали спасибо, ошибку на удаленный компонент поправим, и влияет ли она на долгую загрузку — проверим. Моб. админ постарается быть повнимательнее к жалобам, он там явно перегнул.

В Alpha 11 будет исправлено, спасибо! На самом деле он выключается, интерфейс не показывает.

Переместил тему в раздел про Мобильное приложение. Возможно, из-за наведения порядка в ответах JSON версии 4.2, будем разбираться после праздников.

Собралось 4.2 Alpha 9.

Хотфикс пересобирается.

Конфиг больше так не выкладывайте. Пришлите файл self-test скрытым сообщением. Если роутер не даёт зайти, висит, отключайте от него по одному кабели, USB, Wi-Fi-устройства, пока не найдете внешнюю причину. В журнале (входит в self-test) останутся записи Ваших действий, и что было до них.

Видимо, устройство предназначалось для продаж в указанных странах, но что-то напутали с отгрузками. Это исправляется через поддержку. Они выяснят id устройства и помогут исправить.

Точно не норма, что вопрос задан без диагностики. Невозможно сказать, что именно не так, и на чьей стороне. Рекомендуем обратиться в официальную поддержку. (Либо давайте в отдельной теме и во всех подробностях.)

Открытой документации нет, поэтому проще всего посмотреть в консоли браузера, что делает веб-интерфейс. Общий подход такой, что в rci-запросах (API) используются те же названия команд и аргументов, что и в CLI. Поэтому для работы с API в некоторой степени подходит документация по CLI. Входные и выходные данные отформатированы как JSON, как именно — видно в консоли. Например: При нажатии кнопки "Сохранить":

Статическая ARP-запись не сотрется. Только не забудьте сохранить конфиг после ввода команды (system configuration save). ARP-запись такого вида нужна только для работы WoL в режиме broadcast, причем в сценарии, когда это нужно сделать удаленно через правило перенаправления UDP/9. IP-адрес (192.168.2.254) можно выбрать любой не занятый, и он нужен для работы этого правила. Для работы через Web-интерфейс ничего в ARP прописывать не нужно. Кинетик просто отправит WoL-пакет на MAC-адрес желаемого хоста. То же самое делается из командной строки: ip hotspot wake 11:11:35:e2:77:60

self-test скрытым сообщением. интернет должен быть подключен. можно пару попыток зайти через KeenDNS перед этим

Cloud — неофициальный проект, разработанный параллельно с моб. приложением.

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

Проблема временно лечится установкой компонента cloudcontrol (клиент мобильного приложения). Режим public можно не включать, достаточно просто установить. Задачу создали, будет исправлено в ближайшем выпуске Alpha.

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

Спасибо! Исправление перенесено в 4.0, т.е. войдет в следующий релиз. 4.0 сейчас на регрессионном тестировании, preview будет на следующей неделе. Пока можете пользоваться 4.1.