Denis P

на 4.2.6.3 была довольно простая логика при 0 или вообще отсутствии PersistentKeepalive в конфиге автоматом ставилось 30, все были довольны и не возникало вопросов у пользователей в 4.3 вы это поведение изменили, что и вызвало проблемы у людей которые и не знают про существование этого параметра и обязательном его наличии конкретно для кинетика. Другим клиентам оно не надо, даже при работе за nat (но это уже совсем другая история и тема разговора)

+ chrome и ff такое же поведение

Для отправки запросов непосредственно с роутера - нет

всё именно так и задумано, в других роутерах где используется SQM алгоритм точно такой же

отключите, эти поля заполнять не обязательно.

Это то тут при чем?) у вас многопирный конфиг aka server. Тема совсем про другое

Используйте в entware метки политик, делов то) На форуме даже примеры были

В политике с приоритетами подключений (интерфейсов) выбор тоже довольно очевиден, не совсем понятно по какой причине он вам не понравился)

Добавьте разрешающие правила в межсетевом экране на этом интерфейсе и всё будет ходить

а вы попробуйте, ничего никому не мешает. Судя по постам ни один человек даже и не проверял как и что работает сейчас.

тут на самом деле всё немного проще, после обновления до А8, оно и не включается само, если компонента не было) если было - тоже слетает, но это похоже на баг альфа версии "ipv6 subnet Default", " bind Bridge0", " mode slaac", " prefix length 64", " number 0", т.е вот это не прописывается, проблемы и нет по сути)

суть всех жалоб можно свести к - "сделайте кнопочку отключения ipv6 еще и в сегментах" а пока(?) её нет, вот вам в помощь: ipv6 subnet Default no bind

на месте они...

у меня немного другие источники информации, в этом весь "цимес"

и.. кто сказал что не используются разные адреса из разных подсетей? прямо сейчас вижу 4 адреса из абсолютно разных подсетей и даже разных локаций, такие дела

да, именно в этом и проблема, что он продолжает себе спокойно распознаваться. про все соединения это так, чтоб уж наверняка

да ладно бы это какие-то остатки, я не совсем корректно выразился про "падение" скорости, до и после применения фильтра т.е разницы может и не быть вовсе, полагаю правильным будет таки сбрасывать все коннекты клиента после применения фильтрации, для применения ограничений на лету, а то смысл всего этого немного теряется селф тест на всякий случай ниже

удалите все днсы + игнор днсов провайдера включите opkg dns-override и пользуйтесь только agh вот таким образом, все запросы из политик будут ходит в agh.

Вы и из группы тг решили с этим прийти, ну ок, напишу вам то же самое. Укажите адрес agh в интернет фильтрах 192.168.2.1:53 (именно с портом) и живите спокойно. А в netfilter заглядывать не нужно.

укажите pvid - 1 (хотя тут разницы быть не должно, если pvid одинаковый и на обоих портах) могу предположить что вы домашнюю сеть отправили с тэгом на самом кинетике, покажите как конфигурация выглядит в данный момент

точно так же как и для порта 4-1, pvid тоже

на портах в сторону других кинетиков у вас должны быть транки с нужными vlan + native vlan для основного сегмента и "связи" с контроллером

всё именно так и работает https://help.keenetic.ru/hc/ru/articles/4403264852498-Аппаратная-TDR-диагностика-Ethernet-кабелей-в-Peak-Giant-Ultra-SE-и-Ultra-KN-1811

это кто вам такое сказал? даже цельный onlink есть, для того чтобы принудительно указать "возможно" недоступный шлюз за конкретным интерфейсом

как именно работает? давайте разберемся с этим) если у вас будет 5 интерфейсов с дефолтным маршрутом 0.0.0.0/0 точно ничего хорошего не произойдет Для этого кинетик и не делает дефолтный роут, а используются политики (приоритеты) подключений и статические маршруты, чтобы четко разделять через что и куда должны ходить пакеты. Да, это немного сложнее, но более гибко и наглядно. Ничего плохого в этом не вижу, но я и не разработчик, только высказываю свое субъективное мнение