Leaderboard

Всем спасибо, найдено и починено. Если кратко, то причина была в росте размера структуры tcp_skb_cb, которая начала конфликтовать с флагами ppe software, из-за чего когда байт в skb->cb[46] становился равен 0x4 происходил отброс пакетов. Вообще нужно отметить странную политику расположения полей с tcp_skb_cb в ядре 4.9. Если поменять поля в union tx : оба skb_mstamp поставить в начале (они требуют выравнивания по 8), а u32 в конце, то структура будет занимать не 48, а 44 байта. И такой проблемы никогда бы ни было. Ну да ладно. И проявляется это кстати везде, а не только на 7621 - но на нем локальный трафик заметнее и чаще используем. Хочется сердечно поблагодарить всех за упорные репорты этой проблемы - без них мы бы не поняли реальную важность, и сочли бы ее возможным аппаратным багом или глюками ПО на клиентах - что, на нашей практике, бывает все же чаще. Но отдельная благодарность объявляется господину @KorDen за настойчивость, исследование и выделение минимального сетапа для воспроизведения ситуации. Также он был первым, кто обратил внимание на связь jiffies с потерями (мы и сами до самого конца не верили, что дело в этом) и выявил конкретный диапазон. И его догадка в итоге привела нас к разрешению ситуации. Еще раз хочется отметить, что это был не просто наброс в стиле "не работает, быстро чините, б...дь" или "после обновления не стоит, жена ушла к другому, сын гей"; а технически выверенный репорт с указанием как воспроизводить (и даже скриптом). За этот образцовый багрепорт @KorDen отблагодарим самым новым и крутым устройством, которое появится уже скоро. Еще раз всем спасибо.

Версия 2.16.D.1.0-1: curl: обновлен до версии 7.68.0 dropbear: обновлен до версии 2019.78 OpenVPN: добавлена поддержка шифра CHACHA20-POLY1305 VPN: исправлено подключение Android-клиентов с симптомами: ppp-pptp: fsm timeout ppp: compressor dropped pkt исправлено добавление маршрутов с флагом "auto" и явным адресом шлюза SSTP: отключены опции accm, accomp, pcomp для совместимости с VPN Client Pro (сообщил @vasek00) Udpxy: количество клиентов увеличено до 32 SSH: добавлена настройка таймаута для ssh-сессии: ip ssh session timeout {timeout} IPv6: устранены возможные перезагрузки при использовании VLAN Adguard DNS: исправлено определение доступности сервиса IPsec: удалены все лимиты по количеству туннелей HTTP: proxy: добавлена передача заголовков Connection и Upgrade для работы WebSocket SNMP: исправлены CVE-2020-6058, CVE-2020-6059, CVE-2020-6060 DNS: реализован ответ NOTIMPL на запрос IQUERY(1)

Версия 3.3.7 (официальная бета): Wi-Fi: восстановлена скорость обмена данными с LAN-сегментом (сообщил @vasek00) Wi-Fi: исправлено подключение AppleWatch с включенным роумингом Web: ускорена работа при обращении к списку хостов (сообщил @biospb) Web: исправлена работа страницы "Проброс портов" (сообщил @r3L4x) Web: добавлен индикатор загрузки для папок в файловом браузере Web: исправлен редирект на страницу "Ваш браузер не поддерживается" в IE11 (сообщил @Duber) DSL: добавлена настройка DSL SNR Margin: interface Dsl0 vdsl snr-margin {4..30} interface Dsl0 adsl snr-margin-offset {-10..10} MWS: ускорено подключение экстендеров по Wi-Fi MWS: улучшен механизм выбора оптимального канала IPsec: улучшена стабильность работы в режиме аппаратного ускорения IPsec: восстановлена совместимость с фрагментацией на уровне IP Adguard: исправлены ошибки 'unable to extract domain from request' TSMB: исправлена перезагрузка службы WSD при настройке "ip alias" (сообщил @m__a__l) TSMB: исправлено отображение файлов названиями, превышающими 255 байт Добавлена поддержка USB-модемов: Digma Dongle DW1961 Digma Dongle DMW1969 DECT: добавлена поддержка трубки Panasonic KX-TG6821

Версия 3.4 Alpha 1: HTTP: реализована поддержка WebDAV — https://{hostname}/webdav (по просьбе @MDP) ip http webdav enable — включить сервис ip http webdav security-level (public | private) — включить/выключить доступ из интернета ip http webdav permissive — отключить проверку файловых ACL ip http webdav root {directory} — настроить корневой каталог user {name} tag webdav — включить доступ пользователю {name} show ip http webdav — вывести состояние службы SSH: реализована поддержка SFTP (по просьбе @krass) ip ssh sftp enable — включить сервис ip ssh sftp permissive — отключить проверку файловых ACL ip ssh sftp root {directory} — настроить корневой каталог user {name} tag sftp — включить доступ пользователю {name} show ssh sftp — вывести состояние службы USB: реализована поддержка модемов с интерфейсом QMI: Qualcomm MDM9207 (PID 9025) SIMCom 7100E, 7230E, 7600E Anydata W140 Sierra MC7710 Quectel EC25-E Megafon E392, E397, E398, EC106, E352, M100-1 MTS 320D, EC306 Longcheer LU1107 ZTE MF821D USB: добавлена поддержка модемов: Digma DW1961, DMW1969 Tele2 D402 MWS: реализовано отключение беспроводной backhaul-точки доступа (по просьбе @Loredan) mws backhaul shutdown DNS: реализована блокировка DNS Rebinding (по просьбе @SecretSanta) [no] dns-proxy rebind-protect (strict | auto) auto — блокировка адресов, входящих в текущие private-подсети (включено по умолчанию) strict — блокировка всех адресов из списка IANA IPv4 Special-Purpose Address Registry DNS: реализован ответ NOTIMPL на запрос IQUERY(1) DLNA: реализована поддержка VPN-клиентов: user {name} tag vpn-dlna — включить доступ пользователю {name} 802.1x: исправлена авторизация PEAP/MS-CHAPv2 (сообщил @Алексей Подвойский) Web: ускорена работа интерфейса при большом количестве маршрутов (сообщил @Alexander Kudrevatykh) SNMP: исправлены CVE-2020-6058, CVE-2020-6059, CVE-2020-6060 включено аппаратное ускорение передачи пакетов между Wi-Fi и GigabitEthernet0 через Bridge на mt7621

Версия 3.3.10 (официальный релиз): Wi-Fi: исправлено отображение клиентов, подключенных через усилители/адаптеры AdguardDNS: исправлена проверка доступности сервиса (сообщил @vai73) Web: включена генерация ключей при создании подключений Wireguard

Версия 2.11.D.5.0-1: curl: обновлен до версии 7.68.0 OpenVPN: добавлена поддержка шифра CHACHA20-POLY1305 Udpxy: количество клиентов увеличено до 32 IPv6: устранены возможные перезагрузки при использовании VLAN IPsec: удалены все лимиты по количеству туннелей HTTP: proxy: добавлена передача заголовков Connection и Upgrade для работы WebSocket SNMP: исправлены CVE-2020-6058, CVE-2020-6059, CVE-2020-6060 DNS: реализован ответ NOTIMPL на запрос IQUERY(1) Собрано в delta/draft для KIII/KDSL/KLTE/KVOX.

Версия 3.3.8 (официальная бета): исправлено поведение светодиода "Интернет" (сообщил @keenet07) исправлена частота опроса хостов по ARP (сообщил @r13) TSMB: исправлено переименование файлов для ФС, нечувствительных к регистру

Версия 3.3.9 (официальная бета): исправлено повреждение TCP-подключений на 3-й день работы (сообщил @KorDen) Web: исправлено сохранение профиля VDSL

3.4 — экспериментальная ветка на ядре Linux 4.9, см. также историю изменений 3.3. Поддерживаемые модели: Keenetic Giga III Keenetic Ultra II Keenetic Air Keenetic Extra II Giga (KN-1010) Start (KN-1110) 4G (KN-1210) Lite (KN-1310) Omni (KN-1410) City (KN-1510) Air (KN-1610, KN-1611) Extra (KN-1710, KN-1711) Ultra (KN-1810) Viva (KN-1910) DSL (KN-2010) Duo (KN-2110) Speedster (KN-3010)

Всем спасибо, воспроизвели и нашли причину. В следующей сборке все будет ок.

Версия 3.4 Alpha 3: исправлен сбой в очереди задач при извлечении USB-накопителя (сообщил @Nikolaiyka) исправлено подключение Wireguard после перезагрузки (сообщил @bigpu) Web: исправлено сохранение имени системы (сообщил @Vvlysov) Web: исправлена работа мастера быстрой настройки для устройств с DSL-портом (KN-2010, KN-2110) HTTP: исправлена передача заголовка Host при проксировании

Версия 3.4 Alpha 2: MWS: исправлено применение MAC-фильтров на экстендерах MWS: исправлено обнаружение экстендеров со статическим адресом Web: исправлен статус в дополнительных свойствах подключения (сообщил @stakp) Web: восстановлен выключатель USB-модема (сообщил @TheBB) Web: восстановлены переводы (сообщил @AndreBA)

В продолжение темы в 3.1, резюмирую: Рвутся TCP-соединения (как минимум на 7621, у меня Ultra KN-1810) спустя несколько десятков-сотен переданных Мб, когда аптайм приблизительно в районе 3-4 дня. Очень похоже на jfifies (TCP Timestamps), потому что 0x04 00 00 00 = 67108864 /250=268435 = 3d 02:33:55 0x05 00 00 00 = 83886080 /250=335544 = 3d 21:12:24 Лаги начинаются где-то с 3d 02:44 и продолжаются до 3d 21:16, дальше всё работает без глюков. На практике у меня были аптаймы до 15 дней, в другое время, кроме 3 дня, подобного не замечал (хотя захожу не каждый день, мог и пропустить). Отключение TCP Timestamps посредством "echo 0 > /proc/sys/net/ipv4/tcp_timestamps" не решает проблему У меня рвется с самых первых драфтов 3.x SSH/HTTP/HTTPS снаружи, но есть исключения в определенных вариантах сети за WAN. Локально проблемы не наблюдаю. Просто воткнуться снаружи в WAN похоже недостаточно. У @Space Alex и @Supermaks глючит DLNA c аналогичными симптомами, я DLNA не пользуюсь.

3.4 давно пора бы выпустить. Но! Пришлось пойти на принцип — найти ошибку "третьего дня" и не распылять силы уважаемого Сообщества. 3.3.9 нужно дать три дня на проверку, и мы её отправим в stable, и включим раздачу 3.4 в драфте. Пока такой план.

Есть две новости. Я добавил в dropbear поддержку chacha20-poly1305@openssh.com, на практике для KN-1010 это означает увеличение скорости записи с 3 до 6,5 Мбайт/сек. Плохая новость заключается в том, что хоть sftp drive поддерживает этот шифр, он у них реализован криво и не работает (совместимость с реализациями openssh, winscp и putty проверена, это не наш баг). Потому нужно их попинать в техподдержку, чтобы починили, и тогда наступит счастье. Также начиная со следующей сборки dropbear начнет поддерживать ключи ed25519, нужно их сгенерить через > ip ssh keygen ed25519 или сбросить устройство И еще - через команду ip ssh cipher можно будет задать (в порядке убывания приоритета) шифры, которые вы хотите использовать. Пока доступно 3 - chacha20-poly1305@openssh.com, aes128-ctr и aes256-ctr.

Версия 3.3.11 (официальная бета): MWS: исправлено применение MAC-фильтров на экстендерах Wi-Fi: исправлена проблема неподключения клиента при длительном отсутствии вышестоящей точки доступа 802.1x: исправлена авторизация PEAP/MS-CHAPv2 (сообщил @Алексей Подвойский) Версия 3.3.12 (официальная бета): Web: исправлена работа мастера быстрой настройки для устройств с DSL-портом (KN-2010, KN-2110)

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

Беспроводной backhaul работает и на 2.4, и на 5 ГГц. Две сети нужны для подключения разных экстендеров, в том числе однодиапазонных. В прошивке 3.4 появится команда отключения беспроводных backhaul-точек с сохранением работы Wi-Fi-системы по проводу.

Всем привет. Первый раз на форуме, поэтому не знаю есть ли здесь разработчики прошивки, надеюсь да. В общем я программист, пользуюсь вашим роутером и бед не знаю, по качеству ПО полагаю это лучшее решение на рынке. Так же пересадил многих друзей и коллег IT-шников на ваши роутеры, мы все безумно ими довольны. Работают без единого разрыва, как говорится. Так вот, в эту пятницу, в баре за пивом зашел разговор о нашей работе, о наших кинетиках и о всяком IT-шном. И вот в чем вопрос, мы все пришли к выводу, что в кинетиках не хватает одной очень важной вещи SSH-Клиента. Есть куча всего для школьников и домохозяек, от торрент-клиента, до Яндекс-DNS и даже OpenVPN клиента. Но это всё для домашних хомячков. А программисты и IT-специалисты часто пользуются SSH тоннелями до своих рабочих серверов, баз данных, рабочих компьютеров и прочего оборудования. И им тоже нужны плюшки Точнее нам) За пивом, с коллегами, мы поделились общей бедой, у многих дома постоянно открыты SSH тоннели, много к чему и как, у кого-то динамический прокси настроен и прочее. И для всего этого необходимо постоянно держать открытыми Putty, OpenSSH клиент, termius, kitty и прочие SSH клиенты, которые работают как тоннели или прокси, но без консоли (флаги -NT). И вот на меня возложили обязанность написать сюда) Было бы неплохо добавить в стандартную прошивку полнофункциональный ssh-клиент (чтобы работали все пробросы портов, туннели и прокси) или хотя бы сделать такой пакет-расширение для установки. Чтобы можно было поднять прокси до рабочей машины командой типа этой ssh -NTFakx -R 127.0.0.1:22344:127.0.0.1:4444 -i privkey.sshkey -N root@workcomp.ru на роутере и забыть о висящей программе на компьютере. Или допустим на роуетере через ssh-клиент у тебя будет поднят тоннель до базы MySQL на работе, и вот ты подключаешься на адрес 192.168.1.1:3315 и попадаешь на рабочий компьютер на порт 3306 по SSH тоннелю. Это же круто как удобно. Ребят, очень просим) очень надо) Вещь простая, даже SSH сервер в роутерах есть, а клиента нет, ну как так то:-) OPKG даже не предлагайте) Это для садомазохистов. Если добавите - респект от всего IT сообщества!

@stakp, @r777ay, @AndreBA проблема будет исправлена в следующей сборке. Спасибо за репорт!

Версия 0.5.59 (2020-02-16): Исправлен цвет текста в названии WAN-порта (для Keenetic OS >= 3.4; сообщил @AndreBA) Исправлен стиль описания каналов автообновления (сообщил @AndreBA) Исправлен стиль описания профилей доступа на странице "Мои сети и Wi-Fi" (сообщил @AndreBA)

Сейчас для всех туннелей задано жесткое значение lifebytes в 20 гигабайт, из-за чего имеются проблемы с передачей через туннель больших объемов за раз. Как вариант расширить имеющееся "crypto ipsec transform-set <set> lifetime <seconds>" до цисковского "crypto ipsec security-association lifetime {seconds seconds | kilobytes kilobytes}" (шепотом: и для 2.16.D, если реально)

Я крайний противник движения к проприетарным расширениям WG, потому пальцем не пошевелю, пока не будет нормальной инструкции.

Потому что более тупых логов чем у кенентика в этом вопросе я не видел ни у кого. Я уже поднимал вопрос по этому поводу. Почему в логах нет IP атакующего. Просто не понятно. Как всякой фигней логи забивать, так пожалуйста. А как отображать IP атакующего так фиг вам. Это один из главных вопросов безопасности роутера. IP в логах отображается только когда IP получает бан. Ну хоть что то. Но я уже приводил пример, когда у меня идет раз в сутки атака с одного IP и он в логах не отображается. То есть, он раз в сутки заходит, делает попытку подобрать пароль и уходит. И так каждый день.

В версия ОС 3.4 Alpha 2 исправлено. Спасибо!

А как хочется видеть вылизанный релиз хоть раз, видно не судьба. 😞

3.3 — стабильная ветка на ядре Linux 4.9 Вот даже не смотря на то что в changelog ветка 3.3 позеленела и стала стабильной, хотел бы обратить внимание уважаемых разработчиков на то что эта проблема никуда не исчезла. У меня 17 устройств трудятся в сети аптек, которые я обслуживаю. Исторически сложилось так что сегментом "гостевая сеть" пользуются сотрудники массовых позиций и там есть текучка. Проблема решалась контролем доступа. А сейчас он не работает. Устройств не мало и конфигурация инфраструктуры в офисах разная. Что-то переделывать сложно, т.к. все это хозяйство в работе каждый день. Но и ничего не делать я не могу. Клиенты задают вопросы.. Я понимаю что это все мои проблемы. И мой к Вам вопрос только один: сообщите примерные сроки исправления. Благодарю.

KeenDNS это не только служба доменных имен, но и облачный сервис посредник, позволяющий получать доступ к клиентам с серым ip. У вас как раз такой случай, но не типовой, а с полной переадресацией о которой KeenDNS не знает и поэтому работает по "серой схеме", ориентируясь на серый адрес на WAN, позволяя вам получить доступ находясь за NAT. То что NAT при этом открыт и можно через него ходить напрямую KeenDNS не сообщили. Noip же обычная DynDNS служба, которая просто выдаёт ip и всё. За NAT вы или нет noip не интересует. Сравнивать эти две службы некорректно. Это не баг, а схема работы. Белый ip - прямой доступ, серый ip - облачный доступ. ip определяется по WAN. Тут речь идёт о необходимости третьего сценария серый ip - прямой доступ с выдачей внешнего ip на DNS запросы. Этот вопрос больше для раздела "Развитие" подходит. Баг это когда всё идёт не по плану, а в данном случае KeenDNS отрабатывает штатно, как и было задумано.

Отправляйтесь в официальную техподдержку, пожалуйста.

Они плавно поменяли сервера, но без предупреждения. Потому у васти еще работало, а у части уже нет.

Сбор пакетов на WAN показывает, что адгард все же лезет dns-запросом на dns-family.adguard.com и dnscheck-default.adguard.com. Первый резолвится, а второй нет. Нужно ли это функционалу или нет, не знаю, но возможно именно недоступность второго адреса и вызывает ошибку доступности всего сразу. Адрес этот совсем недоступен, и через другие DNS тоже.

В будущий 3.4 внесли изменения, которые позволят обойтись без костылей с пинг-чеком.

Так он же на 3DES преимущественно, на AES-128 и выше там требуемый объем в эксабайты, не? Вот только rekey в кинетике вызывает пересогласование всего соединения с переподнятием линка и потерей пакетов, и хорошо если не всех соседних туннелей "за компанию".

Микросхема свича MT7530 агрегирование L2 не поддерживает и не научится. В целом, агрегирование L2 (пока статическое, без LACP, и не на текущих моделях устройств, а только на будущих) запланировано в работу. Под эту функцию будет ставиться свич Realtek, на котором она аппаратно поддерживается.

Le ecureuil Доброго дня, если правильно понял, то речь идёт о параметре "не уменьшать TTL". Галочка не стояла, но сам посыл, как мне подумалось правильный. Посмотрел выгруженный self-test, нашёл, правда там он выглядит так: ip adjust-ttl inc 1 Решил так, сбросил настройки, загрузил 3.3.2 и через ("firmware" - заменить файл) - залил Всё супер, скорость отличная.. Всем здоровья, сил, удачи и терпения.

Потому что роутер в таком режиме в маяке выставляет все поддерживаемые им режимы безопасности. И если тупой/кривой/косой клиент видит что-то неподдерживаемое, он должен это просто аккуратно пропустить, а он видимо пытается либо интерпретировать по-своему, или вообще падает в ужасе. Такое поведение невозможно исправить со стороны роутера, только выключив WPA3. Аналогичное дерьмо кстати происходит если включить 11r FT, или WPA-Enterprise. Весь форум забит сообщениями о косых клиентах, которые не умеют корректно видеть что-то отличное от Open или WPA2-PSK. При чем здесь роутер-то?

Правильно сделать так - выставить вручную MTU 1500 на eoip, и забриджевать его. Тогда все будет работать нормально, в том числе и фрагментация. Проверять стоит на версии > 3.3.3, которая еще только выйдет - там как раз есть исправления на эту тему.

Подергал на грани перехода - действительно, проблема исчезает в 3d 21:17:24, а не 3d 21:16:46 Короче, менять INITIAL_JIFFIES и не ждать 3 дня.

Аааа! лол! jiffies же на 5 минут отстает от uptime! Поэтому не FFFF, а 124F8! @sergeyk, возникает резонный вопрос, а чего бы не взять и #define INITIAL_JIFFIES 0x03FF0000 Ну чтобы не ждать 3 дня... (если дело действительно в jiffies)

Да, тоже воспроизводим. Будем чинить - но не факт, что к следующей сборке - баг не горящий. Спасибо за репорт.

3.4 Alpha 1, трубка S850HX, при входящих-исходящих звонках отсутствует слышимость удаленной стороны (сервер->роутер), явно не проключается входящий RTP ни в early media, ни во время разговора. В дампе RTP имеется, на 3.3.10 всё работает. Ping @des

Для более гибкой настройки беспроводной сети на устройствах входящих в Wi-Fi систему хотелось бы иметь возможность независимого выбора диапазонов на каждом из них. Зачастую могут возникать ситуации, когда на каком-либо из устройств в Wi-Fi системе необходимо отключить один из диапазонов, например на одной из точек доступа выключить 2.4 ГГц, чтобы клиенты к ней подключались только на 5 ГГц. В нынешней реализации это невозможно: на подчиненной точке доступа ползунок неактивен, при отключении интерфейса через cli после перезагрузки настройки синхронизируются с контроллером и вернутся к исходному значению. К примеру имеется Wi-Fi система из Giga KN-1010 и двух Omni KN-1410, в которой Giga выступает в качестве контроллера и на ней возникла необходимость отключения 2.4 ГГц. При выполнении этого действия на Giga полностью отключится и беспроводная сеть на обоих Omni KN-1410, ведь они вещают только в одном диапазоне 2.4 ГГц, который был отключен на Giga. На свой взгляд вижу два варианта реализации этого функционала: 1. Разрешить вкл/выкл band на подчиненных устройствах, при этом считать настройку сделанную локально на подчиненной точке более приоритетной, чтобы она не "затиралась" при очередном разливе настроек с контроллера; 2. Прибегнуть к более сложному, но более правильному, на мой взгляд, дизайнерскому решению: в контроллере Wi-Fi системы в списке устройств дать возможность выбора band для каждого подчиненного устройства. Выглядеть это бы могло следующим образом (см. аттач). Поддержавших идею прошу голосовать.

добрый день kn-1010 прошивка 3.4 Alpha 1 после отключения пира wireguard продолжает писать в лог большое количество сообщений. ранее по данному вопросу были заросы №468149 471417 с версии 3.3.2 количество записей сократилось и после 20 попыток записи в лог прекращались на 3.4 Alpha 1 пир отключился от wireguard примерно в 00:40-00:50, при этом записи в лог продолжались до следующего дня 12:04 (далее уже выключил wireguard на роутере) лог и self-тест ниже скрытым постом

Одно другому не мешает: исправляем ошибки 3.3 и работаем над 3.4 параллельно, спасибо за понимание.

Версия 0.5.58 (2020-02-01): На дашборд добавлены ссылки на "Статистику подключений" для включенных VPN-серверов

Идея, на самом деле, рассматривается к реализации независимо от того, понравится она кому-то на этом форуме или нет. Здесь она вряд ли найдет отклик, не стоит тратить нервы. Если говорить о бизнес-применении, то помимо 2FA нужен целый набор функций, позволяющий обслуживать все устройства в единой системе (мониторинг, резервное копирование, база пользователей и их гаджетов и т.д.), и для этого обычно делают облачный сервис, "добавляют" в него устройства, и вход в сервис автоматически даёт доступ ко всему, что там есть.

@shadowy правилами маршрутизации, например: ip route 195.181.161.80 192.168.209.1 GigabitEthernet0/Vlan4 auto ip route 185.152.65.182 192.168.209.1 GigabitEthernet0/Vlan4 auto где: 185.152.65.182 - endpoint адрес сервера wg-провайдера, например anonine.com: 192.168.209.1 - адрес шлюза интерфейса GigabitEthernet0/Vlan4 - backup интерфейс nslookup cz.anonine.net ╤хЁтхЁ: UnKnown Address: 192.168.11.1 Не заслуживающий доверия ответ: ╚ь : cz.anonine.net Addresses: 2a02:6ea0:c228::2 2a02:6ea0:c227::2 185.152.65.182 195.181.161.80 Таким образом Вы настроите маршрутизацию через нужный Вам интерфейс. В будущем будет добавлен 'connect via' - "Подключаться через".

Да, точнее когда uptime в промежутке 268697s - 335544s (3d 02:38:17 - 3d 21:16:46; 0x4010000 - 0x500FFFF) поломаны ретрансмиссии TCP. Только на MT7621. Воспроизводится с самого первого публичного драфта 3.00 и по настоящее время. ЗЫ: актуализируйте исходники 4.9 на гитхабе

Воспроизвёл проблему на WiFi. Итого, правильное описание бага: В промежутке 268697s - 335544s (3d 02:38:17 - 3d 21:16:46; 0x4010000 - 0x500FFFF) поломаны ретрансмиссии TCP. В дампе от роутера (на WifiMaster0/AccessPoint0) ретрансмиссии есть, до клиента не долетают (хотя сеть уже восстановилась). Стоит аптайму выйти за этот период - и ретрансмиссии уже летят корректно. Проявляется везде - на WiFi, LAN, WAN На уме вертится CVE-2019-11478 (хотя там про другое), но это ведь было летом, а проблему я кажется заметил раньше. Да и потом, система получается ретрансмиссии отправляет, кто их не пускает наружу?

"... Дело было вечером, Делать было нечего..." ( "А что у вас?" С. В. Михалков) ~ # ~ # ndmq -p "show version" -P device Keenetic Omni II ~ # ~ # ndmq -p "show version" -P release 2.16.D.1.0-0 ~ # wireguard-go_0.0.20191012-1_all.ipk (mipsel)