dimon27254

@eralde @Anna_ @Test Pilot Установлена автоматическая тема оформления веб-интерфейса. Веб выбирает темный вариант в соответствии с настройками браузера. Если нажать на кнопку печати QR-кода, чтобы вызвать браузерный диалог печати, то тема переключается в светлую. Как только диалог закрывается, тема снова возвращается на темную. Как я понимаю, поведение связано с работой браузера. Однако, можно ли как-то со стороны веба ограничить переключение на время вызова печати, чтобы не было данных "миганий"? Пусть веб остается в темном виде, но QR-код распечатается в светлом варианте. Именно так работает сейчас, если вручную выбрана темная тема оформления. Проверял на NC-1812 с 5.1 Beta 0.1.

@eralde @Anna_ В данной версии исключено раздельное управление сетями 2.4 и 5 ГГц, привязанных к сегменту. Предлагаю сделать переход к настройкам нужной сети по щелчку на её название в карточке. По моему мнению, это наиболее простой и быстрый способ "провалиться" в нужную страницу. Кнопка "изменить", исходя из реального опыта и текста, ведет сразу на управление расписанием, а не общие настройки.

@eralde @Anna_ @Test Pilot В новой версии данной карточки меня крайне смущает несоразмерность круговой диаграммы по отношению к легенде: Может быть, лучше сделать "бублик" побольше, а ширину легенды уменьшить? Сейчас выглядит не аккуратно и странновато. Проверял на NC-1812.

@eralde @Anna_ @Test Pilot Если полностью отключить один из диапазонов Wi-Fi (выключить все связанные с ним сети сегментов), то при обращении на страницу Сегменты или Точки доступа появляется оповещение: Оно не пропадает с экрана, пока соответствующий диапазон выключен. Даже при переходе на другие страницы в рамках одной сессии. Оповещение выглядит немного незаконченным. Должно ли оно вообще отображаться? Проверял на NC-2312 с 5.1 Beta 0.1.

@eralde @Anna_ @Test Pilot 1. Здесь не помешало бы также убрать все упоминания о 6 ГГц на роутерах, где этого диапазона пока нет - что в селекторе FT, что в меню выбора Band Steering. 2. В продолжение сообщения: Настройки FT действительно не отображаются: Однако, если кликнуть по любому диапазону, то ранее введенные параметры роуминга появятся. 3. Поле "ключ мобильного домена" теперь оформлено как обычное текстовое, значение более не скрывается. 3.1. Не помешало бы для данного поля исключить ввод кириллицы, чтобы не получилось вот так: Проверял на NC-1812.

Веб-интерфейс и так минималистичен и скуден на цвета, а тут даже в названии бренда этот цвет "забрали")

Может быть, через годик-другой все таки появится лоадер 🥲

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

Геоблокировка не накапливает адреса. Она использует загруженные списки и по ним ограничивает доступ. Просмотр загруженных списков геоблокировки недоступен, так не имеет смысла - там может быть до 100 тысяч адресов, смотреть на которые в консоли или ещё где-либо точно не будет удобно.

Пришлите, пожалуйста, в личные сообщения self-test. Попробую посмотреть, в чем у вас может быть дело.

Как вы проверили, что у вас действительно eth3? Может быть, там будет eth2.2 или что-то другое.

Геоблокировка тоже не работает? Маловато вводных. Может быть, не выбран правильный интерфейс, или же у вас серый IP-адрес.

К сожалению, в 5.1 Alpha 7 каких-либо положительных изменений не увидел. Включил dns-proxy debug, и, кажется, NDMS решила новые IP домена просто пропустить, отдав только клиенту. Ниже self-test с включенным dns-proxy debug. Время запроса 18:56:16, на сервере 18:56:17. @admin может быть, все-таки рассмотрите вариант сделать обработку запросов, как это реализовано в dnsmasq? По сути, входной и выходной точкой всех запросов является ndnproxy, в том числе в политиках. Нельзя ли его "научить" извлекать IP-адреса из ответов upstream и загружать в object-group fqdn налету? Чтобы избавиться от всего того, что сделано сейчас и работает не совсем хорошо. Я ранее пользовался dnsmasq, сейчас в основном MagiTrickle - там все работает идеально. Хотелось бы видеть, что также идеально все работало и "в стоке". Текущая реализация, к сожалению, очень далека от идеала.

Кажется, "по многочисленным просьбам" появился тот самый долгожданный oldstable в виде ветки lts_4.3: Однако, переход на него пока недоступен. При обновлении NDSS возвращает ошибку 403:

И это, к сожалению, проблема. Предположим, роутер получил от провайдера белый IP 1.2.3.4. В него же резолвится домен. Пока само подключение работает, все хорошо - из локальной сети можно успешно зайти по домену на роутер, никаких проблем не возникнет. Однако, как только это самое подключение отвалится, или же сменится внешний IP-адрес (вместо 1.2.3.4 провайдер выдаст 4.5.6.7), доступ к вебу из локальной сети окажется невозможен, потому что домен ссылается на старый IP, который больше доступен. Приходится ждать некоторое время, пока обновятся DNS-записи у резервного провайдера, чтобы я смог зайти в веб именно по домену. Простой пример, как можно себе "выстрелить в ногу" из локальной сети при "текущем положении дел": зайти в веб-интерфейс по домену, и выключить основное подключение с белым IP. Веб-интерфейс сразу же перестанет работать, потому что внешний IP оказывается недоступным. Другой пример: Спокойно пользуемся интернетом, "ничего не предвещает беды". По какой-то причине провайдер с белым адресом отваливается. Я через облако получаю уведомление, что подключение недоступно. Хочу быстренько сразу же зайти в веб из локальной сети по домену и посмотреть, что произошло, а не получится - домен ссылается на недоступный IP. Можно, конечно, просто заходить в веб из локальной сети по локальному IP, но я с самого момента перехода на Кинетики привык заходить в веб-интерфейс даже из локальной сети по домену. Поэтому данное изменение не считаю корректным.

Да, так запись возвращается. Это ожидаемое поведение в последних 5.0 и 5.1? Раньше я помню, что из локальной сети CrazeDNS-домен всегда возвращал 78.47.125.180, вне зависимости от режима доступа.

В таких условиях, думаю, лучше ответить, что запрос обработает первый, кто перехватит запрос на IP 78.47.125.180.

Откроется главный, через который вы выходите в интернет.

Да, у меня тоже начало возвращать 78.47.125.180. Значит, подправили после моего сообщения 🙂 Спасибо!

И этот вариант не корректен 😁 Везде в инструкциях и на коробках Неткрейзиков пишется my.netcraze.net. А значит, должно работать по нему 🙂

Я не считаю это полноценным решением. Если вдруг у пользователя просто в браузере или на устройстве будет стоять публичный DNS вместо Неткрейзика - он уже не попадет по my.netcraze.net. В Кинетиках же можно использовать хоть какой DNS - все равно гарантировано будет работать my.keenetic.net.

78.47.125.180 в роутере "вшит", однако чтобы устройство на него могло попасть, нужно как-то ему подсказать, что за доменом my.netcraze.net числится тот самый 78.47.125.180. Домен my.keenetic.net с любого DNS, даже публичного, всегда разрешается в 78.47.125.180. А в my.netcraze.net при использовании сторонних DNS можно увидеть, что там оказываются IP-адреса серверов Selectel, используемых Netcraze.

В 5.0 и 5.1 гиперссылка уже работает. Мы её долго ждали, но когда-то дождались. Спасибо 🙂

@Anna_, нет ли каких-нибудь новостей по возвращению "цвета" в кнопки удаления?

@Anna_ В 5.1 Alpha 6 все еще актуально.