keenet07

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

В приоритетах подключений настраивается. Создаете отдельную политику. Добавляете туда источник интернета VPN и устройства которые должны через него выходить. Другие источники интернета туда не пихаете. Будет работать как заказывали.

Тоже норм. Попробуйте CTRL+F5 во вкладке админки в браузере. Вообще это бы неплохо делать после каждого обновления. Часто в кэше остаются устаревшие данные.

Он может и не включен был. По скринам же не понятно. Там все его режимы заскринены. ) А вот зарегистрировать устройство (новый кинетик) в списке клиентов точно нужно, если он в списке ещё не присутствует.

WhiteList у вас зачем-то настроен. Либо выключите его. Либо добавьте туда мак-адрес вашего нового роутера. Ваш микротик в нем присутствует. Поэтому и работает через него. Или всё-таки у вас там выбрано Не использовать?

Ничего не понимаю, откуда спидстер взялся? Оптика у вас как и в какой роутер заходит?

Старому (микротику) дает потому-что адресация отличная от starter. Сделайте чтоб разные подсети DHCP были у Starter и 3811 раз вы из вместе соединяете. Так подключаете? inet->(WAN-Starter-LAN)->(WAN-3811)

Попробуйте через домен войти. Раньше вроде было так. https://my.keenetic.net

Понятно. ) Не рабочая тема.

Для чего это делать в развернутом меню? Оно на то и развёрнутое, что всё развёрнуто. Может быть тогда лучше сделать управление каждой группой меню в свёрнутом режиме? Сейчас там может быть развернута только одна группа за раз. А если сделать возможность развернуть сразу несколько? Ну и естественно чтоб запоминалось в браузере.

У вас скриншота этой настройки нет? Может быть там наоборот, "игнорировать настройки DNS выданные удаленным сервером"?

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

@eralde У меня просьба по той же теме, но немного в другом ракурсе. Такой вопрос уже поднимался. При переходе на страницу "Приложения" перед её отрисовкой происходит запрос к серверам обновлений Кинетик, чтобы получить список неустановленных, но доступных к установке компонентов относящихся к Приложениям. И в тех случаях когда доступ к серверам отсутствует (офф-лайн статус или доступ наружу заблокирован) происходит ожидание в несколько десятков секунд с крутящейся звездочкой и только после этого отображается содержимое страницы на которой отсутствует вкладка "Показать все", потому-что списка нет. Отображаются только установленные приложения. Возможно ли как-то оптимизировать этот механизм, так, чтобы страница в отсутствии этих данных загружалась сразу, чтоб не происходило этого фриза интерфейса. А уже потом происходил запрос о доступных к установке приложений? Например, можно отобразить вкладку "Показать все" и если данные по компонентам уже получены, то отобразить их, а если нет, то не отображать. Ну либо как-то ещё иначе. На сколько я заметил, при получении данных о компонентах они кэшируются и единожды полученные, при повторном переходе "не установленные приложения" отобразятся всё-равно, не зависимо от повторного доступа к серверам обновлений.

Анализ трафика приложений

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

Предлагаете эту текстовую информацию хранить в конфиге роутера? Или просто в памяти браузера? Во втором случае эта штука только автономно работать будет.

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

Это только пока кажется ненужным и не интересным. Ещё слишком слаба интеграция со сценариями умного дома. А вернее пока она вообще отсутствует. Но обязательно появится. А там очень много сценариев можно прописать и тогда очень захочется чтобы всё срабатывало адекватно.

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

Можно условно разделить эти типы wifi клиентов на два класса. Это низкоскоростные стационарные (IoT, датчики) и высокоскоростные (телефоны, ноутбуки и т.д.). Классифицировать их по разным признакам (по MAC и другим идентификаторам). Для высокоскоростных использовать более агрессивную проверку активности (периодический ping и т.д.), учитывать падение уровня сигнала перед отключением. А для низкоскоростных установить более длительный период таймаута. Так же можно анализировать паттерны работы таких устройств, например передает данные раз в 10 минут и прочие способы. Внедрить адаптивный механизм который будет учиться на основе истории поведения устройств и будет автоматически корректировать параметры отключения. Но если хочется проще всё это решить, то позволить вручную относить то или иное устройство к определенному классу с соответствующей тактикой проверки статуса онлайн.

Снова поднимаю данную тему, но внесу ряд конкретных новых предложений для полноценного управления маршрутами в веб-интерфейсе. Предлагаю добавить следующие возможности: 1. Внести столбец включения/отключения каждого пользовательского маршрута с помощью переключателя, как это реализовано в Межсетевом экране. 2. Внести столбец выбора/отметки каждого маршрута, так же как в Межсетевом экране. Только действиями для выбранных объектов будет не перемещение между вкладками, как в Межсетевом экране, а изменение Интерфейса у выбранных маршрутов. Т.е. если нужно для группы выбранных маршрутов поменять интерфейс через который должен пойти трафик. Например, переключить группу маршрутов на другой VPN. Саму возможность выбора Интерфейса реализовать через такое-же появляющееся при выборе нескольких объектов выпадающее меню с выбором Интерфейсов, по аналогии с перемещением правил между вкладками в Межсетевом экране. 3. Добавить функционал создания нового маршрута на основе уже существующего. Тут подход может быть разным. Предлагаю сделать, чтоб когда мы выбираем галочкой одно из правил, активировалась/появлялась кнопка "Создать на основе выбранного" и при её нажатии создавалось точно такое же правило, как выбранное включая все его настройки и описание, но добавлялось оно в отключенном состоянии. см. пункт 1. Дальше заходим в него и меняем то что необходимо (IP, интерфейс, описание, доп настройки.) Далее активируем новое правило переключателем. Либо, другой вариант сделать так как предлагалось ранее в отдельной теме кнопки в самом окне настройки маршрута: 4. Групповое удаление выбранных маршрутов. Ставим галочки, активируется кнопка удалить выбранное.

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

Развитие темы и внедрение.

Вышла beta 3? На форуме по beta 2 ещё молчок в Журнале изменений. Забыли что ли сообщение открыть?

По этому вопросу не подскажу. Но в любом случае, чтоб избежать утечек WebRTC нужно либо блокировать его, либо направлять весь UDP трафик через этот самый прокси. Ну возможно ещё заблокировать для клиента/устройства весь трафик, кроме самого прокси, если такое приемлемо.