hellonow

@Серов Николай исправление вошло в версию 3.9.5 и 4.0 Alpha 13

@Андрей Шевелёв после установки WG2 интерфейса через PPPoE0 перестал устанавливаться хэндшейк с удаленным пиром: [I] Mar 15 21:43:39 ndm: Wireguard::Interface: "Wireguard2": reconnecting peer "pEjb23238mtCLSQyUzKQBgHeSVMmEA=" via "PPPoE0". [I] Mar 15 21:43:39 ndm: Wireguard::Interface: "Wireguard2": added a host route to peer "pEjbuc/2323r/8mtCLSQyUzKQBgHeSVMmEA=" (85.209.2.183) via PPPoE0 (PPPoE0). [I] Mar 15 21:51:11 kernel: wireguard: Wireguard2: retrying handshake with peer "pEjbuc/ЫВЫВr/8mtCLSQyUzKQBgHeSVMmEA=" (5) (85.209.2.183:61791) because we stopped hearing back after 15 seconds [I] Mar 15 21:51:17 kernel: wireguard: Wireguard2: handshake for peer "pEjbuc/at4EZER8SЫВЫВUzKQBgHeSVMmEA=" (5) (85.209.2.183:61791) did not complete after 5 seconds, retrying (try 2) [I] Mar 15 21:51:33 kernel: wireguard: Wireguard2: retrying handshake with peer "pEjbuc/atЫВSQyUzKQBgHeSVMmEA=" (5) (85.209.2.183:61791) because we stopped hearing back after 15 seconds [I] Mar 15 21:51:38 kernel: wireguard: Wireguard2: handshake for peer "pEjbuc/at4EZER8SzЫВЫВSQyUzKQBgHeSVMmEA=" (5) (85.209.2.183:61791) did not complete after 5 seconds, retrying (try 2) Если отключить PPPoE и оставить подключение UsbLte0 Fibocom L860-GL, то туннель будет устанавливаться корректно? И self-test файл лучше прикреплять в скрытом сообщение.

@KCAHDEP @roman_sh @vasek00 еще раз всем спасибо. Гарантировано получилось воспроизвести с WG-интерфейсами, которые идут друг за другом в профиле политик по умолчанию - таблица маршрутизации _254. Когда отключаем интерфейс - подключение для доступа в интернет с маршрутом по умолчанию, то на последующем WG-интерфейсе возникает шторм исходящих пакетов. Исправление планируется в будущих версиях draft.

@dimon27254 @AndreBA в новой draft версии будет исправление, поэтому просьба проверить подсчет трафика и отображение отдачи в WebUI.

@dimon27254 спасибо, заведен кейс, ожидаем исправление в будущих версиях ПО.

@Sergey Zozulya только в LinuxOS системе воспроизводится? WinOS, AndroidOS, iOS? Попробовал выполнить в WinOS, не воспроизводится с вашей конфигурацией ip host и update-dns включенного для сегмента сети. Версия 4.0.10 ping -n 5 my.comp Обмен пакетами с my.comp [192.168.15.50] с 32 байтами данных: Ответ от 192.168.15.50: число байт=32 время<1мс TTL=128 Ответ от 192.168.15.50: число байт=32 время<1мс TTL=128 Ответ от 192.168.15.50: число байт=32 время<1мс TTL=128 Ответ от 192.168.15.50: число байт=32 время<1мс TTL=128 Ответ от 192.168.15.50: число байт=32 время<1мс TTL=128 Статистика Ping для 192.168.15.50: Пакетов: отправлено = 5, получено = 5, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

@dimon27254 @units @shurings @Zit отключите ускоритель, после проверьте подсчет, изменится ли ситуация? @Zit если у вас нет, то проверьте без расширения темной темы.

@Artem Kuznetcov сходу не получилось воспроизвести, PrivateDNS работает с транзитом корректно в рамках любых профилей политик и DNS. Проверено с вашей конфигурацией DNS и похожей конфигурацией политик. Проверьте работу в версии 3.9.4 или 4.0.10 И лучше создать отдельную тему, чтобы все в кучу не мешать.

Да, раздел не загружается [C] Jan 1 03:00:11 ndm: Storage::Storagefs: system failed [0xcffd014e]. [C] Jan 1 03:00:11 ndm: lib::libndmStorage: system failed [0xcffd0037], unable to register "storage" filesystem. Всем спасибо. Будет исправлено.

@k19olegh68 в логе возникает ошибка резолва домена удаленного сервера и подключение не может определить тип сетевого протокола: [E] Feb 13 05:02:02 OpenVPN0: RESOLVE: Cannot resolve host address: olegrtn56u.asuscomm.com:4912 (Try again) [W] Feb 13 05:02:02 OpenVPN0: Could not determine IPv4/IPv6 protocol Попробуйте добавить директивы в конфигурацию .ovpn файла: pull-filter ignore "block-ipv6" proto udp4 или pull-filter ignore "block-ipv6" proto tcp4 Зависит от транспорта. После проверьте подключение. Если не поможет, то тогда удалите компонент IPv6 и проверьте работу.

@vasek00 спасибо, воспроизвелось и в другом сценарии, когда WG маршрутизируется через WISP. Достаточно в down перевести интерфейс WifiMaster1/WifiStation0, как почти сразу начинается шторм.

@vasek00 можно подробнее? Вы переводите интерфейс в down и TSMB останавливается? Сейчас готовится исправление для TSMB связанное с: Поэтому проверьте с новой версией draft.

Исправлено в версиях 3.9.3 и 4.0 Alpha 2

@snark то, что сервис DoH падает - следствие. Похоже провайдер ограничивает работу протокола, либо указанного адреса. Так с любым адресом DoH? Как обстоят дела с DoT?

@Timoha исправление войдет в следующую версию ПО 3.9 Пока можете проверить работу в 4.0

@alkovk У приложения отдельная коммутация к серверу, которая осуществляется по протоколу CoAP на базе UDP пакетов, отдельно от службы KeenDNS. В описанные вами моменты доступ по доменному имени службы KeenDNS есть? Нужен self-test файл скаченный в момент возникновения "постоянно появляется сообщение о недоступности то одного, то другого (на 4 минуты), а потом всё восстанавливается". Возможно аплинк падает в эти моменты.

Нужен дамп сетевого трафика в момент подключения, в WinOS. Если у вас есть обращение в поддержке, то лучше прислать файл им пожалуйста.

@Winterborn еще раз проверили подключение в WinOS 7 x64 - чистая система, со всеми установленными обновлениями безопасности, актуальными сертификатами. Туннель ставится моментально. Если у вас продолжается описанная ситуация в 3.9, просьба снять дамп сетевого трафика на стороне WinOS-клиента в момент попыток подключения к серверу. Дамп пришлите в скрытом сообщении.

Пока никак, отключить межсетевой экран для протокола IPv6: no ipv6 firewall system configuration save

@volvic проверьте, сейчас должна быть доступна версия ПО 3.09.C.1.0-2 Hotfix был связан с https://t.me/keenetic_firmware/846

@keenet07 да, сейчас есть вопрос с переводом. Будет исправление.

@Sorrel в логе видно, что возникает перед согласованием ключа шифрования WPA3. [I] Dec 13 22:05:41 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster1/AccessPoint0": STA() had associated successfully (FT mode). [E] Dec 13 22:05:41 mtkiappd: L2 broadcast failed: network is down. [I] Dec 13 22:05:41 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster1/AccessPoint0": STA() set key done in WPA3/WPA3PSK. Если подключать к точке с WPA2? Будет возникать ошибка? Напишите пожалуйста в поддержку с полным описанием ситуации.

@mike_t опишите пожалуйста кейс, для каких задач вам нужен работающий модуль?

@hard_alex@mail.ru вышла 3.09.C.1.0-0, проверьте работу IPSec.

@hard_alex@mail.ru к выпуску готовится новая версия 3.9 с дополнительными исправлениями для IPSec. Работу проверьте с ней.