admin

Это касается любых портов, не только "синего". Если его выбрать как Provider, он будет зарезервирован за этим подключением.

Из описания не очень понятно. В каком месте не дает выбрать, пришлите картинку. И смотреть надо сразу на 4.1 (Dev).

Вы обозначили три не связанные друг с другом проблемы, нужно с ними разбираться. По поводу ip alias — действительно сломали, будет исправлено. По поводу остального: просьба прислать диагностику в техподдержку. В частности, ложное срабатывание блокировки в приложении можно снять, только зная сервис-тег Вашего устройства. Как уже правильно ответили, роутеру от "блокировки" ничего не будет, сообщение касается только приложения. В целом признаем, что в сценариях использования устройств людьми хватает тонкостей, которые не выявляются даже на стадии широкого бета-тестирования. Все обращения в поддержку сейчас классифицируются и берутся в работу.

Подправили, в следующей сборке заработает.

В процессе работы над новым интерфейсом его тестовые версии будут доступны для установки параллельно с текущим интерфейсом. Можно будет переключаться из нового в старый, т.к. в новом не всё будет работать. Оба интерфейса точно будут тяжелее, чем один, и вы правы — на таких устройствах, как KN-1110, бессмысленно собирать подобную конструкцию. Мы соберем его только для моделей, где места побольше.

Не хочется расстраивать, но "что-то" — видимо, и есть сам момент подключения. Видимо, кто успел подключиться, те не смогут, если сбросят настройки.

Клиент к облаку V2 на версии 2.16 пришлось бы обновлять и тестировать заново. Текущий вариант не работает не из-за "маркетинга", а по чисто техническим причинам.

Отладки полно, только она предназначена для внутреннего пользования. По таким вопросам обращайтесь в поддержку и не морочьте никому голову. Чтобы понять, с каким сервером проблемы, смотрите "show ndss".

Обновляйтесь на 4.0 Beta 0.2. Для KN-2710 и KN-1811 увеличено число политик до 64, и связанные константы также подправлены. Убедительная просьба дать обратную связь. Интересует объем потребляемой памяти и CPU при реальном использовании.

Качество вопроса пока не предполагает ответа. Вы делаете измерение скорости от конечного узла до некоего сервера (предположительно, Speedtest, хотя Вы и этого не сказали), и Вас не устраивает результат. Вы просите угадать причину. Ни версии прошивки, ни качества сигнала до БС, никаких других подробностей не предоставили.

Сколько по-вашему должно быть?

Разобрались, исправим в следующей 4.0, спасибо!

Приложите self-test скрытым постом, пожалуйста. Из обрывков журнала ничего нельзя понять.

@relgames: интересный случай. Пришлите, пожалуйста, self-test с отключенным DS-лайтом. Только если можно, на прошивке 4.0.

В 4.0 Alpha 12 исправлено, причина аналогичная: .

Проблема найдена и исправлена. Войдет в следующий draft Alpha 12. Всем спасибо! Сейчас в качестве "исправления" можно: вернуть ретрансляторы на 3.9.4 или Alpha 10 подключить любой ethernet-порт ретранслятора, чтобы на нём был линк, это заставит его DHCP-клиент запуститься и получить адрес.

Разобрались, исправим.

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

Хороший редирект. Пробуйте добиться такого же при обращении через прокси. Включите curl с печатью заголовков, может быть это наведет на мысль `curl -kv https://192.168.20.200:8080`. Можно внутри `ip http proxy cam` поиграть с настройками: preserve-host — посылать оригинальный заголовок Host, который был до проксирования force-host {host} — посылать принудительно заданный заголовок Host x-real-ip — посылать заголовки X-Real-IP и X-Forwarded-For

Не связан. Покажите фрагмент конфига с настроенным прокси к регистратору. Редирект идет от регистратора. То есть, надо пытаться что-то подкрутить в HTTP-заголовках между кинетиком и ним, что заставит его не редиректить. (Не факт, что удастся.)

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

Есть функция — расписание работы подключений https://help.keenetic.com/hc/ru/articles/360000510999-Расписание-работы-подключений, устройство целиком перезагружать не обязательно. Только обратите внимание (к сожалению, деталей Вы не прислали), что расписание можно назначить как на DSL-подключение, так и на PPPoE-подключение. Веб-интерфейс назначает его на DSL-подключение. Возможно, если у Вас PPPoE, достаточно переназначить его на PPPoE, и тогда не придется ждать повторную синхронизацию DSL. Это можно поменять из командной строки с помощью команды "interface {name} schedule", можете поэкспериментировать. Расписание, привязанное таким образом, выполняет interface up/down в заданное время.

Вам необходимо установить версию 3.9.4 из канала Preview. Там была исправлена ошибка в части, относящейся к TLS-подключениям (NDM-2516), которая хоть и присутствовала, но почти не проявлялась на 3.9.2.

Спасибо, метку "grafana" добавили (правда, всё же не через "ph").