dimon27254

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

@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-система" и там кликать по нужному Кинетику или же вручную авторизовываться на нем при переходе из "Списка устройств".

@eralde по этому поводу были правки? В changelog не увидел упоминаний, но на последних версиях перестало воспроизводиться.

Стоит отметить, что новый веб-интерфейс доступен только на прошивках draft-ветки (канал разработчика): В preview (предварительном) он отсутствует, только что проверил у себя на KN-3610.

@eralde спасибо! В 4.1 Beta 2 состояние чекбокса отображается корректно.

Служба отключается сразу же после ввода команды, но порты, которые были открыты еще во время её работы - остаются. Перезагрузите Кинетик и все записи удалятся.

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

По каким-то причинам у вас нет доступа к серверу обновлений, из-за чего и недоступно удаление службы UPnP. Без полного удаления её можно выключить с помощью пары команд в CLI: no service upnp system configuration save

@eralde в продолжение темы о предупреждающих диалогах: Нашел аналогичный недочет и в диалоге подтверждения извлечения USB-устройства:

@eralde в диалоге подтверждения выключения Wi-Fi сети, через которую подключено устройство, управляющее Кинетиком, затерялось описание: Если эту же сеть попытаться выключить из карточки в dashboard, оно выводится корректно: Проверял на 4.1 Beta 1.

@hellonow @Padavan возникла необходимость на KN-3610 отключить 256-QAM для диапазона 2.4 ГГц из-за проблем со стабильностью подключения некоторых старых устройств. В новом веб-интерфейсе произвел отключение. Убедился, что 256-QAM не работает - канальные скорости клиентов снизились до "стандартных" значений, а из startup-config и running-config для WifiMaster0 удалился параметр vht. Перезагружаю Кинетик, и вижу, что 256-QAM снова включился - стал активным флажок в вебе, канальные скорости подросли. В running-config появился vht, тогда как в startup-config его нет. Получается, его автоматически включила система. В чем возможна причина такого поведения? Стандарт сети для 2.4 ГГц выставлен 802.11b/g/n, для 5 ГГц 802.11a/n/ac/ax. Использую KeeneticOS 4.1 Beta 1. Скрытым сообщением прикрепил self-test до и после перезагрузки.

@eralde нашел парочку небольших багов в поп-апе добавления/изменения правила. 1. Выбираю протокол TCP/UDP, вариант номера порта назначения указал как "равен"/ "меньше..."/ "больше..."/ "диапазон": Далее, не вводя номер(а) портов, выбираю другой протокол, в котором не требуется ввод номера порта или же он "зашит". Кнопка сохранения изменений остается неактивна: 2. Иногда вместо стилизованного выпадающего списка с протоколами отображается стандартный браузерный:

В настоящее время не сохраняется выбор версии интерфейса, всегда открывается новый. Можно обращаться к Кинетику по ссылке вида: http://ip_адрес_или_доменное_имя/index2.html Например: http://192.168.1.1/index2.html https://mykeenetic.keenetic.pro/index2.html В таком случае будет сразу открываться старый веб-интерфейс и им можно будет полноценно пользоваться до следующего входа. Затем снова придется переходить по приведенной выше ссылке.

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

Без изменений в 4.1 Beta 0.1.