Le ecureuil
-
Постов
11 067 -
Зарегистрирован
-
Посещение
-
Победитель дней
648
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
4.3a4 перестаёт принимать соединения WAN
Le ecureuil ответил Scondo вопрос в Тестирование Dev-сборок
Одну из возможных причин устранили, попробуйте на следующей версии 4.3. -
Спасибо за репорт, будет поправлено в следующей версии 4.3.
-
На первый взгляд все в порядке, в self-test зацепок нет, и локально воспроизвести в подобной конфигурации не вышло. Попробуйте убрать conform для этого хоста - чисто для проверки ситуации. Еще неплохо бы проверить работает ли проброс с других WAN, которые сейчас в резерве.
-
Поправлено. Причем причина была в том, как устроен протокол HTTP/2 - и поймать этот баг еще нужно было постараться. Теперь в первом случае будет просто веб, во втором - 502, в третьем - тоже просто веб. Попробуйте на следующей версии 4.3.
-
У вас OpenVPN1 прописывает прилетевший с удаленной стороны роут в 10.1.1.0/24, в то время как в OpenVPN0 ничего не приходит снаружи, и, естественно, ничего не прописывается. Адреса удаленные, на которые вы хотите заходить, лежат в 10.1.1.0/24?
-
Скорее всего MTU кривой, уменьшайте.
-
Текущий вариант в принципе и так уже представляет собой разумный компромисс. Есть много людей, задействованных в разработке и в релизах, процесс выверен уже практически десятком лет, и пока нет очевидных причин для его смены.
-
Все это переделано и должно быть нормально в 4.3. Если есть возможность и желание - лучше проверять там. В 4.2 относительно 4.1 никаких существенных изменений нет.
-
А можете с interface OpenConnect0 debug снять лог (только более-менее большой) и сюда приложить?
-
А зачем это нужно Keenetic можете объяснить? Чтобы клиенты покупали чужие точки доступа (а не наши) и добавляли в нашу WiFi-систему? Спасибо, не нужно. Причем еще и за свой счет обеспечивать совместимость с кучей китайского разношерстного кала.
-
Нет.
-
Все используем. Если можно исправить быстро - исправляем быстро. Если проблема важная, затронуты все - исправляем быстро. Если можно потерпеть и хорошее решение занимает время - значит будет делаться сколько нужно, потому что это Alpha и здесь важнее сделать правильнее, чем быстрее. Упор на скорость обычно только для совсем массовых проблем или для проблем с безопасностью.
-
Отвязал, в 4.3 можно будет ipv6 не ставить.
-
Сейчас проверил, в версии 4.3 такого нет. Site-to-Site IPsec можно спокойно ставить без IPv6, он автоматом не вытягивается.
-
Бесполезно апать, делается в порядке очереди для фич, а это не скоро.
-
Что такое "систематический"? Какая закономерность, характерное время, объем переданного трафика?
-
В 4.3 оно и так уже есть.
-
Если есть возможность, проверьте на версии 4.3.
-
В альфе никто и не обещал, что будет как-то иначе.
-
Хорошее замечание, отвяжем в 4.3, теперь он там не нужен.
-
Это нормально, ручное управление настройкой disable_ipv6 крайне не рекомендуется. Аналогичного эффекта можно достичь просто не поставив компонент IPv6 - это правильный способ решения.
-
- из локальной сети соединение установить нельзя, это особенность реализации. - то, что ваш пользователь не имеет к вам доступа даже посредством ping говорит о том, что Keenetic тут не при чем.
-
Погонял с USB-flashdrive и с USB-SSD дисками для теста в 16 потоков копируя ядро linux (10 тысяч файлов самого разного размера). Да, на USB-flashdrive все туговато, нагрузка на CPU высокая, отвечает медленно, но в итоге все скопировалось хорошо. Основной вклад в нагрузку - это iowait, то есть медленно выполняющиеся операции с накопителем. На USB-SSD все просто летало, нагрузку выше 30% не видел. Вывод - все зависит от накопителя.
-
Нет, 4.2 вышла в stable.
-
Нет, с AES-GCM. Сейчас таких скоростей нет, я только сегодня добавил многопроцессорную обработку.
