dimon27254

В настройках сегмента, а именно параметрах DHCP сервера, укажите DNS-серверы провайдера или любые доступные публичные и сохраните изменения. После этого перезагрузите кинетик. Устройства будут обращаться с DNS-запросами не к кинетику, а напрямую к указанным публичным серверам. Мне это помогло решить проблему с медленной загрузкой сайтов на устройствах. Когда исправление будет выпущено, удалите ранее введённые DNS-серверы из настроек DHCP сервера, перезагрузите кинетик. После этого устройства снова будут обращаться к кинетику.

Аналогичные сообщения имеются и в 4.1 Alpha 3. Также отрицательные значения иногда видны в другом сообщении, которое появляется после длительного отсутствия активности между сервером и клиентом: wireguard: Wireguard0: zeroing out all keys for peer "*" (6) (*.*.*.*:*), since we haven't received a new one in -2130375580 seconds

@admin @Le ecureuil @hellonow после последней перезагрузки весь лог кинетика засыпан записями от ndnproxy вида: [D13B] answer from wrong socket (got from 36 *.*.*.*:53 [268435201] to *.*.*.*:*, exp from 20 *.*.*.*:53 to *). Как я понимаю, это расширенное отображение ошибки, о котором ранее упоминали: В частях "got from" и "exp from" одинаковые адреса DNS-серверов провайдера, как и порт назначения. Self-test прикрепил. Проверял на 4.1 Alpha 3.

Спустя почти сутки с последнего моего сообщения аналогично "посыпался" KN-1212. Там также используются полученные от провайдеров DNS серверы, но в качестве основного соединения UsbQmi, а резервное IPoE. @admin @hellonow с него понадобится self-test, или уже нашли причину поломки ndnproxy?

@eralde в новом вебе обратил внимание, что в плитке "о системе" отсутствуют сведения о количестве активных соединений. Было принято решение эти данные перенести куда-то в новое место, или после открытия страницы "Диагностика" они будут возвращены на свое место?

@eralde В 4.1 Alpha 3 всё исправлено. Спасибо!

ОС Windows 11, браузер Chrome 116. В системе установлен масштаб 125%, возможно это как-то влияет на отображение именно этих цифр. Аналогичная ситуация возникает при установке системного масштаба в 100%, а масштаба страницы 125%.

У меня отсутствуют DoH/DoT серверы, использую полученные от провайдера.

Ранее писал об отсутствии перевода в данной вкладке:

Добрый день! Приведенные выше 6 пунктов мной замечены в 4.1 Alpha 3, только в ней у меня открывается окно просмотра настроек устройства.

Здесь явно имеется зависимость от конфигурации или установленных в системе компонентов, т.к. у меня проявляется только на одном кинетике из трех.

@eralde @Anna Zhelankina еще было бы неплохо, чтобы в значках скачивания стрелку развернули на 180 градусов. Со стороны кинетика, это, конечно, выгрузка, но со стороны пользователя скачивание. Так станет более понятным назначение этой кнопки.

@eralde еще заметил, что при открытом списке клиентов лог кинетика забивается записями: Core::Configurator: not found: "show/rc/ip/traffic-shape/host" [http/rci]. Похоже, где-то еще осталась зависимость от шейпера трафика.

@hellonow @Infy @Le ecureuil в актуальных 4.1 Alpha 3 и 4.0.3 через некоторое время работы начинают сыпаться пачками ошибки вида: [EE57] socket is not ready for request. Сайты стали дольше загружаться, попытки сделать nslookup для доменов проходят не с первого раза, завершаясь таймаутами. В 4.0.2, как 4.1 Alpha 1-2 такого не замечал. Перезагрузка кинетика исправляет проблему, но ненадолго.

Похоже, имеется зависимость от установленных компонентов. Я проверил на Chrome 116.0.5845.97 и Edge 115.0.1901.203, а также в мобильном Chrome 116.0.5845.92, ни в одном из браузеров не работает переход.

@eralde в этом окне заметил немного багов: 1. Не отображается локализованное наименование стандартных сегментов. 2. Пиктограммы кнопок сворачивания/разворачивания разделов инвертированы: Мобильный веб: 3. Кнопка WOL широковата и "выпадает" из общей гаммы: Не будет лучшим в поп-апах также уменьшить поля, чтобы избежать таких багов? 4. При открытии окна фокус сразу устанавливается на поле ввода имени хоста. Из-за этого всплывает системная клавиатура, которая мешает просмотру. Может быть, лучше не устанавливать фокус на текстовые поля, оставив как в 3.х вебе? 5. Кнопка вызова всплывающей подсказки находится довольно близко к кнопке сворачивания/разворачивания раздела. На примере контроля доступа к беспроводной сети это хорошо заметно: 6. В разделе "Переадресация портов" подписи кнопок оказались под таблицей:

@eralde В 4.1 Alpha 3 исправлено. Спасибо!

@corniger в последней 4.1 исправлено. Спасибо!

@eralde в 4.1 Alpha 3 поля уменьшились, теперь места на страницах для контента стало заметно больше. Спасибо, ожидаю исправлений по другим пунктам.

@eralde все замечания поправлены в 4.1 Alpha 3. Спасибо!

@eralde в 4.1 Alpha 3 пункты 2-4, 7, 9-10 исправлены. Спасибо! На глаза еще попалась мелочь: в графике скорости для резервного соединения подписи времени чуть меньше в высоту, чем для основного. Из-за этого выглядят немного сжатыми:

@eralde мобильная версия страницы поправлена в 4.1 Alpha 3. Спасибо! В десктопной версии логотип и модель будут исправлены в будущих релизах? В мобильном вебе мелочь, но все же: логотип компании немного смещен влево относительно центра и модели. Подправьте, пожалуйста, по возможности:

@eralde в 4.1 Alpha 3 все поправлено, спасибо! Правда, появился новый баг: из списка клиентов невозможно перейти на любую другую страницу. В консоли DevTools появляется такая ошибка:

@eralde в 4.1 Alpha 3 язык в коде изменяется, но только после загрузки страницы, а изначально также стоит "en". Из-за этого браузер все равно предлагает сделать перевод. По моим наблюдения, в 3.х вебе в начальном состоянии этот атрибут вообще отсутствует, а после загрузки страницы добавляется в соответствии с выбранным языком.

@Le ecureuil @Infy @hellonow просматривая логи на кинетике (как в 4.1 Alpha 1, так и Alpha 2), обратил внимание, что в записях, касающихся Wireguard, при попытке повторить хэндшейк (ввиду неустойчивости связи с другой стороны) периодически появляются странные временные отметки с отрицательными значениями: wireguard: Wireguard1: retrying handshake with peer "*" (*) (*.*.*.*:*) because we stopped hearing back after -2126184448 seconds В 4.0 и более ранних это значение было всегда положительным, и, как правило, редко превышало 15 секунд, т.е. записи имели вид: wireguard: Wireguard1: retrying handshake with peer "*" (*) (*.*.*.*:*) because we stopped hearing back after 15 seconds Проблем с работой туннелей не испытываю, но такие отрицательные значения смущают.