Перейти к содержанию

admin

Администраторы
  • Постов

    322
  • Зарегистрирован

  • Посещение

  • Победитель дней

    111

Весь контент admin

  1. Навел справки, EZ-net в экспериментах с вышеупомянутой фичей не участвовал. Менеджеры попробуют связаться с ними и подскажут более удобный способ "рулить многими клиентами сразу", но пока вам придется добиваться правды самостоятельно. Они наверно ставят один и тот же админский пароль на кучу устройств, чтобы заходить на них. И поэтому не могут показать конфиг. Но вы скажите, что рулить хотите сами.
  2. Видимо, такую провайдер ему настраивает, но пусть @ZdenniZ сам ответит, начнем с п. 1. Туда мы копаем вообще или нет.
  3. Да, есть такая фича для провайдеров... если вкратце, она работает так, что роутер автоматически соединяется с их системой мониторинга и удаленного входа в интерфейс. И там есть опция заблокировать доступ к интерфейсу из домашней сети. То есть, роутером могут управлять только сотрудники провайдера удаленно. Эта фича тестировалась с несколькими небольшими провайдерами и распространения пока не получила. Давайте по порядку, Определимся, она ли это. Для этого скажите название провайдера. Фича задумывалась строго для тех случаев, когда провайдер предоставляет свое оборудование, а не портит роутер, приобретенный абонентом. Блокировка доступа к интерфейсу из дома или удаленно — это опция. Её можно не включать. И можно настроить так, что при нажатии кнопки "reset" конфиг сбросится к базовым настройкам, которые заданы провайдером, чтобы подключение не отвалилось. Все, что требуется для подключения к провайдеру, настраивается без упомянутой фичи. Нет таких секретных команд, которые недоступны владельцу роутера. Другое дело, что провайдер не хочет их показывать.
  4. Вам нужно создать обращение в поддержку. Установите более свежую версию 4.1 или 4.2 Beta, к обращению приложите файл диагностики self-test, снятый с роутера после возникновения проблемы (ошибки о том, что не удалось соединиться с сервером).
  5. Состояния интерфейсов внутри системы начиная с версии 4.0 были переработаны. В частности, это выражается в наблюдаемом поведении. Слой "link" находится на более низком уровне, и событие о его переходе в "up" приходит раньше, чем успевает поменяться состояние "connected". Подправьте скрипт, чтобы он реагировал на изменение change=connected. События change=link в Вашем случае можно игнорировать.
  6. Пришлите self-test скрытым сообщением, а то приходится гадать. Если у Вас старая версия KeeneticOS и прямой KeenDNS (белый адрес или вход из домашней сети), то виноват может быть браузер с TLS 1.3 hybridized Kyber. Можете либо отключить в браузере, либо поставить свежую KeeneticOS 4.2 из Dev.
  7. Без какой-либо диагностики и точных данных приходится гадать. Клиент выбирает точку сам. Отключите band-steering, и дальше смотрите на клиенте, что он видит — это будут объективные данные:
  8. Приоритет подключения по кабелю работает с самого первого релиза mws, и в Вашем случае проблема может быть связана с настройками коммутатора. Посмотрите в сторону настроек STP. Проверьте переход ретранслятора на провод, исключив коммутатор по дороге: перенесите ретранслятор к контроллеру и убедитесь, что такой сценарий работает без лишних перезагрузок. Если остались вопросы, лучше обратитесь в поддержку, у них есть готовые инструкции на такие случаи. Нужно будет передать им файл с диагностикой, снятый с устройства.
  9. Диагностику приложите скрытым сообщением. И со стабильной версией лучше в поддержку.
  10. Это объяснимо: при входе в web мы явно спрашиваем о новой версии и зажигаем лампочку. Но само облако не делает вызов в сторону устройства, когда выходят обновления, и никогда не делало. Если в web и приложение не заходить, устройство само обращается за "новостями" довольно редко: либо при получении/смене IP-адреса, либо периодически примерно раз в сутки.
  11. Приложение разработано так, чтобы нормально работать с роутером по Wi-Fi, если он при этом не подключен к интернету. Этот сценарий тестируется. Хотя мы и могли что-то упустить, давайте разберемся. Для начала убедитесь, что Ваш телефон во время проверки не перешел на мобильную сеть. Выключите мобильный интернет на телефоне, для чистоты эксперимента оставьте только Wi-Fi. Также убедитесь, что телефон не подключился к другой Wi-Fi-сети. Если проблема сохраняется, попробуем с Вашей помощью разобраться, дальше объясним как.
  12. Всем за детали спасибо, ошибку на удаленный компонент поправим, и влияет ли она на долгую загрузку — проверим. Моб. админ постарается быть повнимательнее к жалобам, он там явно перегнул.
  13. В Alpha 11 будет исправлено, спасибо! На самом деле он выключается, интерфейс не показывает.
  14. Переместил тему в раздел про Мобильное приложение. Возможно, из-за наведения порядка в ответах JSON версии 4.2, будем разбираться после праздников.
  15. Конфиг больше так не выкладывайте. Пришлите файл self-test скрытым сообщением. Если роутер не даёт зайти, висит, отключайте от него по одному кабели, USB, Wi-Fi-устройства, пока не найдете внешнюю причину. В журнале (входит в self-test) останутся записи Ваших действий, и что было до них.
  16. Видимо, устройство предназначалось для продаж в указанных странах, но что-то напутали с отгрузками. Это исправляется через поддержку. Они выяснят id устройства и помогут исправить.
  17. Точно не норма, что вопрос задан без диагностики. Невозможно сказать, что именно не так, и на чьей стороне. Рекомендуем обратиться в официальную поддержку. (Либо давайте в отдельной теме и во всех подробностях.)
  18. admin

    API

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

    Wake On LAN

    Статическая 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
  20. self-test скрытым сообщением. интернет должен быть подключен. можно пару попыток зайти через KeenDNS перед этим
  21. Cloud — неофициальный проект, разработанный параллельно с моб. приложением.
  22. Придется отключать фичи/службы по одной, пока нагрузка не упадет. Хотя бы сузим область поиска.
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.