dimon27254

@eralde возможно ли с помощью GET-запроса выключить/включить определенный интерфейс? С помощью POST-запроса все получается, но интересно, реализуемо ли это через GET. Пробовал "конструкцию" вида: http://192.168.1.1/rci/interface?name=WifiMaster0/AccessPoint1&up=false Но, судя по всему, или что-то упустил, или делаю не так - система просто отвечает текущей конфигурацией этого интерфейса в JSON формате:

@eralde заметил некоторое различие в отображении графиков монитора трафика между веб-интерфейсами. В новом вебе столбцы ограничены 2 Мбит/с, тогда как в текущем подстраиваются под общую максимальную скорость. Проявляется при равномерном потреблении трафика устройствами, когда нет резких скачков. Проверял на KN-1811 с 4.1 Beta 3.

@eralde @Anna Zhelankina в новом вебе перед применением новых настроек беспроводной сети, к которой подключено управляющее устройство, не выводится предупреждение вида: Также обнаружил пустое пространство после портов в блоке "Разъемы сегмента и VLAN": Проверял на KN-1811 с 4.1 Beta 3.

Я проверял на KN-3010 и KN-1811. Оба в режиме "router", на версии 4.1 Beta 3.

@eralde для данной кнопки не запрещен выбор другого действия: В текущем вебе изменение недоступно, как и должно быть:

Стоит отметить, что какая-то проверка в новом вебе на этот порт все равно имеется. Если выбрать другой режим работы порта 1, то кнопка сохранения появляется. Для 2-го же порта этого не происходит. Лучше всего, чтобы выбор был недоступен, как это реализовано в текущем веб-интерфейсе:

@eralde @Anna Zhelankina в мобильном вебе имеет место быть незначительная визуальная погрешность: если модель "короткая" и находится на одной строке с логотипом компании, то смещается чуть выше: Для "длинных" моделей, которые переносятся на другую строку, все в порядке:

@eralde нашел небольшой баг: для 2 порта можно выбрать режим работы, отличный от USB 2.0: При этом, кнопка сохранения изменений не появляется внизу страницы. В текущем вебе для этого порта смена режима недоступна. Проверял на KN-1811 с 4.1 Beta 3.

@eralde обратил внимание на парочку неработающих ссылок. 1. Другие подключения, Wireguard, поп-ап "Настройки подключения", раздел "Настройка пира", тултип около поля "Проверка активности", ссылка на статью "Wireguard VPN". В текущем вебе она ведет на страницу https://help.keenetic.com/hc/ru/articles/360010592379. Работает, пусть и не идеально, ввиду проблем с доступом к Zendesk в РФ. В новом вебе ссылка иная: https://support.keenetic.ru/articles/360010592379. При переходе по ней просто открывается главная страница центра поддержки в доменной зоне ru. 2. Параметры системы, блок "Автоматическое обновление", ссылка на статью "Автоматическое обновление операционной системы". Ситуация аналогичная предыдущей. Проявляется в русскоязычной локализации, где используется три варианта ссылок на базу знаний: help.keenetic.ru/hc/ru, support.keenetic.ru и help.keenetic.com/hc/ru.

@eralde в поп-апе добавления/изменения правила обнаружил, что при смене маски подсети не происходит повторная валидация ранее введенного адреса источника/назначения. Создаю новое правило, в котором указываю адрес подсети источника/назначения, не соответствующий стандартной маске 255.255.255.0. Например, 192.168.100.128. Валидатор, ожидаемо, ругается: Устанавливаю маску 255.255.255.128, но адрес все равно не проходит валидацию: Как только подправляю адрес (например, стираю одну цифру) и затем возвращаю исходный, ошибка пропадает: В текущем вебе этот баг не проявляется.

@eralde 1. При фильтрации записей по параметрам "от" / "к", на выбор доступны не все элементы, имеющиеся по данным журнала. Например, в текущем вебе доступны такие варианты: В новом же, в этот момент, выбор невелик: 2. Ниже строк с записями журнала имеется много пустого пространства, которое можно прокрутить:

@eralde на последних сборках 4.1 заметил, что снова перестало отображаться проводное подключение узлов в Mesh Wi-Fi-системе:

К сожалению, он доступен не для всех Кинетиков:

Поддерживаю, такой сканер был бы просто идеален. Правда, наверное, не факт, что все модемы способны отдать такой объем данных.

@eralde @Anna Zhelankina обратил внимание на некоторые недочеты на этой странице. Проверял в 4.1 Beta 2 с модемом Huawei E3372h-153 на stick-прошивке. 1. Не работает сканирование эфира. Статус "подготовка" в поп-апе сменяется нелокализованным и неизвестным, а само сканирование по факту не начинается: В новом вебе сканер пока что реализован только для модемов типа UsbQmi? В текущем вебе проблем нет, выводятся все доступные сети: 2. Блок выбора диапазонов: 2.1. Имеется лишняя строка "4G LTE-TDD" без доступных вариантов: В текущем вебе она отсутствует: 2.2. В темной теме для чипсов с активными диапазонами используются довольно малоконтрастные цвета. Когда так окрашены все доступные и выбранные по умолчанию band-ы, возникает впечатление, будто они не активны. Хотелось бы, чтобы они четче выделялись окраской. Например, как-то так: 3. Поп-ап "метрики сигнала": 3.1. Он выглядит не совсем красиво в процессе получения с модема данных: Не помешал бы интервал после статуса "подключение...", чтобы поп-ап не был слишком маленьким в высоту в таком случае. 3.2. В этом же поп-апе не увидел кнопки вызова подсказок по параметрам сигнала (RSSI, SINR и т.д.), которая есть в текущем вебе: Было принято решение отказаться от этого? 3.3. В мобильной версии, в таблице блока "информация о подключении", заголовкам выделено маловато ширины: Было бы неплохо, если есть возможность увеличить ширину столбцов с заголовками. В таком случае на видимой области экрана поместится больше полезной информации, т.к. будет меньше переносов строк. 3.4. Совсем мелочь, но которая имеет место быть и в других местах нового веба: инвертирована пиктограмма кнопки скрытия/раскрытия блока:

@vst @eralde На актуальных 4.0.7 и 4.1 Beta 2 уведомление также не отображается. Наверное, его стоит ожидать уже только в новом веб-интерфейсе, когда тот станет доступен для младших Кинетиков?

@SySOPik конфигурация, по сути, идентична моей. Какая версия KeeneticOS используется на клиентах?

Не могли бы, пожалуйста, привести свои настройки сервера и одного из клиентов? ip_сервера - текущий внешний белый ip сервера, новый_ip_сервера:порт - новый внешний ip сервера и порт, старый_ip_сервера - старый внешний ip сервера. Лог приводил с клиента. Настройки довольно стандартные. Сервер: interface Wireguard1 description Server security-level public ip address 172.16.21.1 255.255.255.0 ip mtu 1324 ip access-group _WEBADMIN_Wireguard1 in ip tcp adjust-mss pmtu wireguard listen-port 54321 wireguard peer публичный_ключ_клиента !client allow-ips 172.16.21.2 255.255.255.255 allow-ips удаленная_подсеть_на_клиенте 255.255.255.0 connect ! up ! Клиент: interface Wireguard2 description Client security-level public ip address 172.16.21.2 255.255.255.0 ip mtu 1324 ip access-group _WEBADMIN_Wireguard2 in ip tcp adjust-mss pmtu wireguard peer публичный_ключ_сервера !server endpoint *.keenetic.link:54321 keepalive-interval 24 allow-ips 172.16.21.1 255.255.255.255 allow-ips удаленная_подсеть_на_сервере 255.255.255.0 connect ! up ! Другой вариант - клиент с использованием ping-check: ping-check profile WG host 172.16.21.1 update-interval 30 mode icmp max-fails 5 timeout 5 ! interface Wireguard2 description Client security-level public ip address 172.16.21.2 255.255.255.0 ip mtu 1324 ip access-group _WEBADMIN_Wireguard2 in ip tcp adjust-mss pmtu ping-check profile WG ping-check restart wireguard peer публичный_ключ_сервера !server endpoint *.keenetic.link:54321 keepalive-interval 24 allow-ips 172.16.21.1 255.255.255.255 allow-ips удаленная_подсеть_на_сервере 255.255.255.0 connect ! up ! удаленная_подсеть_на_клиенте - сегмент "домашняя сеть" на KN-3010, удаленная_подсеть_на_сервере - сегмент "домашняя сеть" на KN-3610.

У вас трафик в туннеле идет непрерывно, т.е. имеется постоянная активность? Клиент имеет белый или серый адрес? У меня активность туннеля большую часть времени поддерживается лишь с помощью keepalive-пакетов, которые клиент посылает серверу. К работе KeenDNS вопросов нет - он корректно отрабатывает смену IP, т.к. уже через пару минут веб-интерфейс сервера становится снова доступен из интернета, а nslookup для домена показывает новый IP. Причем, эту проверку я провожу на устройстве, находящемся в локальной сети KN-3010. То есть, встроенный dns-proxy этого Кинетика уже знает новый IP и отдает его клиентам. В 4.1 при первом запуске Wireguard или изменении его настроек, происходит резолвинг и определение IP-адреса конечной точки: ndm: Wireguard::Interface: "Wireguard2": resolved peer "*" endpoint to "ip_сервера". ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": remote endpoint is "ip_сервера". ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": connecting via "PPPoE0" (PPPoE0). ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": local endpoint is "внешний_ip_клиента". При перезапуске Wireguard не появляется запись вида "resolved peer", продолжается использование ранее полученного IP без повторного резолвинга: kernel: wireguard: Wireguard2: peer "*" (15) (старый_ip_сервера:порт) destroyed ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": remote endpoint is "старый_ip_сервера". ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": connecting via "PPPoE0" (PPPoE0). ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": local endpoint is "внешний_ip_клиента". kernel: wireguard: Wireguard2: peer "*" (16) created kernel: wireguard: Wireguard2: handshake for peer "*" (16) (старый_ip_сервера:порт) did not complete after 2164841720 seconds, retrying (try 5) Далее лог забивается записями о неудачных попытках завершения хэндшейка. В 4.0 и более ранних резолвинг происходит при каждом запуске Wireguard: kernel: wireguard: Wireguard2: peer "*" (11) (старый_ip_сервера:порт) destroyed kernel: wireguard: Wireguard2: peer "*" (12) created ndm: Wireguard::Interface: "Wireguard2": added a host route to peer "*" (новый_ip_сервера) via PPPoE0 (PPPoE0). ndm: Wireguard::Interface: "Wireguard2": peer "*" went offline, update configuration. kernel: wireguard: Wireguard2: handshake for peer "*" (12) (новый_ip_сервера:порт) did not complete after 5 seconds, retrying (try 2) Затем туннель поднимается и все работает корректно.

Потеря связи на несколько минут вообще не проблема. В моем случае без привязки профиля ping-check клиент продолжает "стучаться" на старый адрес, пока Wireguard-интерфейс не будет перезапущен. После перезапуска системой выполняется повторный резолвинг домена и подключение идет по новому IP. Так работает на KeeneticOS 4.0 и ниже. На KeeneticOS 4.1 система резолвит домен однократно, при первом запуске интерфейса или после изменения его настроек. Далее, сколько угодно раз можно выключать-включать интерфейс, IP-адрес конечной точки остается от первого резолвинга, повторно эта операция не выполняется. В итоге, клиент никогда не "достучится" до сервера, т.к. IP остается старый и не обновляется

Именно так у меня и настроено: На сервере имеется домен вида *.keenetic.link, а на клиенте этот же домен прописан в конечной точке.

Поздравляю всех с наступающим Новым годом! Мне потребовалось связать два Кинетика с помощью Wireguard-туннеля. В роли сервера выступает KN-3610 с доменом KeenDNS и динамическим белым IP-адресом. Клиентом является KN-3010, на котором в качестве конечной точки указан домен сервера. На KN-3610 периодически меняется IP. Чтобы KN-3010 не терял связь в такой ситуации, создал профиль ping-check, в котором указан внутренний адрес сервера для постоянной проверки. Профиль назначен для Wireguard-интерфейса с параметром restart. Когда сервер перестает отвечать на ping из-за смены внешнего IP, на клиенте автоматически перезапускается Wireguard-интерфейс. В таком случае происходит повторный резолвинг конечной точки, после чего соединение с сервером идет уже по новому IP-адресу. На KeeneticOS 4.0 и более ранних версиях эта "схема" корректно отрабатывала. В 4.1 же обнаружил, что клиент после перезапуска интерфейса продолжает использовать "старый" IP-адрес конечной точки. Перезапуск интернет-соединения, ручной перезапуск интерфейса (в том числе, выключение на некоторое время и затем повторное включение) не исправляет ситуацию. Туннель возможно вернуть "в строй", если изменить любую настройку в Wireguard-интерфейсе, или же полностью перезагрузить KN-3010. Теперь конечная точка туннеля будет резолвиться системой однократно за весь период работы, или это баг? Было бы неплохо, чтобы резолвинг выполнялся при каждом запуске Wireguard-интерфейса, как раньше. При наличии статического IP на сервере, разумеется, не было бы и проблемы, но перейти на статику нет возможности. Скрытым сообщением прикрепил self-test с клиента на 4.0.7 и 4.1 Beta 2.

На актуальной 4.1 Beta 2 все аналогично. Предположил, что влиять на логику работы dns-proxy может исправление NDM-2990. Но там были правки для статических DNS-серверов, тогда как в моем случае получение идет через DHCP. Если перезагрузить резервное подключение, то полученный DNS-сервер начинает использоваться. При назначении устройству политики доступа в интернет через это подключение - никаких проблем с DNS не наблюдается. @hellonow @sergeyk

@hellonow @Le ecureuil в 4.1 Beta 2 отметки времени стали положительными, но значения продолжают быть нереалистичными: wireguard: Wireguard1: retrying handshake with peer "*" (8) (*) because we stopped hearing back after 2166337568 seconds wireguard: Wireguard1: handshake for peer "*" (8) (*) did not complete after 2368404880 seconds, retrying (try 0)

@eralde @Anna Zhelankina сейчас при переходе в веб-интерфейс ретранслятора из "Списка клиентов" требуется вручную проходить авторизацию, т.к. переход идет по IP-адресу. Было бы удобно, чтобы прямо с этой страницы имелась возможность попасть на ретранслятор по доменному имени без необходимости ввода логина и пароля, как это реализовано на странице "Wi-Fi-система". Если же на ретрансляторе, например, нет SSL-сертификата, тогда переходить по IP без автоматической авторизации. Это, конечно, мелочь, но в таком случае переход займет чуть меньше времени, т.к. не потребуется открывать отдельно страницу "Wi-Fi-система" и там кликать по нужному Кинетику или же вручную авторизовываться на нем при переходе из "Списка устройств".