Le ecureuil

Для устаревших моделей такой разницы нет, из одной бочки все наливается.

Покажите дамп трафика на подлежащем соединении, посмотрим.

Ну раз так, то это баг сушилки. Похоже что она запомнила старый адрес и продолжает по нему отвечать.

У вас слишком сильно заполняется conntrack, срабатывает защита от переполнения. Если вы в этом не подозреваете действий злоумышленников, то поднимите порог повыше, с 80 до 98%: > ip conntrack lockout threshold public 98 Или как альтернативу, можете поднять число conntrack-записей до 24 тысяч скажем.

Потому что по DHCP невозможно отозвать адрес, если он уже выдан устройству. А вы в середине процесса взяли и присвоили .1.90 кому-то еще. Попробуйте роутер перезагрузить, чтобы машина переподключилась к WiFi. Должно нормальзоваться.

Покажите свой self-test, когда не работает, с ним будет понятнее.

А чем вам именно delta горит? Поставьте draft. Он все равно эквивалентны.

xt_multiport на этой версии уже собран статически, никаких модулей не нужно.

Сделайте для них отдельный сегмент где выключен DHCP-сервер.

Сделаем, не спешите.

Расскажите-ка, как вы в HTTP/3 сможете посмотреть на URL. Или хотя бы в HTTP/2/TLS. Очень интересно.

Никакой спецлогики и не будет. Для ki_ra/ki_rb 4.3 последняя, потому у нее будет 4.3 и в delta, и в draft. Для ku_rd/kng_re в delta 4.3, в draft пока еще 5.0. Для 1x10 в delta 4.1, в draft 4.3, так как она последняя для них.

Значит что в этих каналах уже лежала 4.3, но более старая. В дельте для 1x10 сейчас 4.01, это для фанатов старого веба и кому новое просто не умещается по месту.

Поставил собираться 4.3.6.2 для ki_ra/rb, kng_re, ku_rd в delta, для KN-1[1..7]10 - в draft.

Реализовано в 5.0.

Реализовано в 5.0.

iperf3 реализован в 5.0.

Реализовано в 5.0.

Реализовано в 5.0.

Пока это все в стадии продумывания. Сейчас на самом деле в общем случае даже выходной IP конкретного запроса узнать - та еще задача, поскольку может быть десяток WAN, пара политик, и хосты перемешаны между политиками с разными WAN, также могут быть DNS-серверы лежащие внутри периметров сетей предприятия со спецдоменами, также на некоторые хосты могут быть явно повешены профили или фильтры, а также на WAN-интерфейсе может быть непубличный адрес. Вот как только в этом всем комплексе настроек будет понятно как использовать ECS, то можно обсуждать его внедрение. Делать же чтобы это работало "по-тупому": в основной политике без фильтров только на основном WAN очень не хочется, это точно не улучшит пользовательский опыт.

Кстати, авторы RFC тоже думают что ECS должен быть выключен по-умолчанию: https://datatracker.ietf.org/doc/html/rfc7871#section-2

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

Еще как является - поскольку этот форум не является официальной поддержкой или официальной книгой обращений, то на этом форуме только мое личное мнение и желание что-то делать играет роль (в темах про DNS как минимум).

Не всегда роутер знает свое местоположение и даже примерный реальный адрес. Вот например выдали ему что-то из CGNAT или из RFC1918 private, что он должен подставить в ECS?

Покажите пожалуйста лог, включив перед этим > interface Bridge0 debug