Le ecureuil

Утечка в 1 случае не является проблемой, так как на короткое время на основном соединении нет адреса, и логично что его роль на короткое время перехватывает резервное. А вот во втором непонятно - что означает "перезапуск"?

Тоже появится в виде команды interface openconnect no dtls

Давайте поподробнее, что именно вы настроили и по какому протоколу обращаетесь?

Спасибо за репорт, проверим.

Вам здесь объяснили технические причины. А на понт будете в другом месте брать, здесь некого.

Возможно он у вас просто "устал". Посмотрите в логе загрузки, там по идее написано, если чип не найден.

Никак.

А не покажете еще логи на кинетике-сервере до кучи?

То есть по вашему утверждению, с сервера 4.3 на клиент 4.3 подключиться невозможно?

В следующей версии 4.3 в клиенте при выборе accept-routes будут приниматься внешние роуты, будет работает получение и настройка IPv6-адресов. Также в сервере появится команда oc-server route для задания маршрутов, которые уйдут клиентам.

Можно и уже сейчас на устройствах с arm64, но пока мы очень стараемся не допустить сегментации по фичам (кроме USB). А иначе выйдет так, что dnscrypt будет доступен только на устройствах с arm64 - и мы немного устанем объяснять, как же понять, на какой конкретно модели эта фича есть, а на какой - точно нет, и покупатьее нельзя. Даже с USB и то постоянно есть проблемы в этом плане.

Исполняемый файл на C занимает 100-200 кбайт в бинарном виде, на Go - 10 мегабайт. В ОЗУ пропорции аналогичные. Потребление процессора тоже возрастает.

Это вариант на Go, а было сверху сказано, что нужно на C.

@Edikward @nastya05-11 обратитесь, пожалуйста, в официальную поддержку.

Покажешь репу на github?

Не существует нормальной реализации DNSCryptv2 на C.

Компетентные органы сообщили, что ситуация должна исправиться.

Просто он похоже уже устал.

@avn пока это не было доделано, но в работу взято.

Есть мнение, что баг не в роутере, а в браузере. Раньше мы использовали сессионные куки, которые обязаны полностью удаляться после закрытия браузера и перезагрузки. Однако выяснилось, что уже пару лет браузеры игнорируют RFC, и хранят сессионные куки вечно из-за фичи под названием "Восстановление сессии". Теперь в 4.3 мы перешли на обычные куки с ограничением срока их жизни именно для того, чтобы они не "висели" в браузере вечно - и вот видимо смесь старых и новых вызывает какую-то странную реакцию. Попробуйте проверить, помогает ли полное закрытие браузера и перезагрузка ПК с неподходящим паролем.

Стоимость их поддержки - околонулевая, и еще есть активные пользователи.

Поправлено, в следующей версии 4.3 будет все нормально.

Вторую точно нет, а для первой между interface и usb нужен аргумент в виде имени интерфейса.

Более тщательно проверить маршруты, возможно часть из них используется и этими сервисами. Потому что на маршруты, отличные от default route, политики не действовуют. Чтобы в политику не копировались маршруты от vpn, не включенного в нее, используйте команду ip policy Policy0 standalone.

На 3.5 никогда этого не будет.