Le ecureuil

KN-2011 lacks USB support, so these modules are unavailable in official releases. But you can use Keenetic SDK.

It's rather strange to insert link just to login page. We are considering to add personal links to all profiles. Stay tuned )

Благодаря @r13 найдена причина, будет исправлено в выпуске 3.6.A12.

@Leksey118 прошу прощения за столь долгий ответ - был занят.
Вообще, настройки очень странные - аж на трех интерфейсах одинаковые DNS-сервера...
Но нашел небольшой баг, который приводил к неработоспособности в proxy - в следующем выпуске должно быть поправлено.

Причина найдена, должно быть поправлено в следующих сборках.

Явно настроить совсем разные DNS для разных политик пока невозможно. Можно только указать, какие будут использованы в той или иной из общих.

Будет поправлено в следующих релизах.

Поправлено.

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

На публичной точке доступа ежедневная проходимость может быть и до десятка тысяч уникальных хостов в гостевом сегменте в день.
Предлагаете для всех них хранить информацию и тратить процессор?

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

Всем спасибо, найдено и починено.
Если кратко, то причина была в росте размера структуры 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 отблагодарим самым новым и крутым устройством, которое появится уже скоро.
Еще раз всем спасибо.

Короче сделали команду
> no ip http easy-access
оно уже доступно в 3.01 beta, и отключает bind на :80 если порт сменен.

Да, ситуация воспроизвелась, но, формально говоря, это не ошибка - это следствие работы фильтра.
При включенных интернет-фильтрах у нас включается блокировка транзитного DoH и DoT - чтобы никто не смог убежать наружу сквозь фильтры.
При этом adguard проверяет себя через https-запрос на 443 порт на свои же домены и сервера, используемые для DNS - а мы этот транзит блокируем, потому что считаем его "попыткой пробежать мимо".
Вот он и не показывает сам себя.
Потому призываю всех не беспокоиться, все работает как заявлено, и даже еще жестче в плане блокировки утечек 

В итоге под пристальным взором нашли источник проблемы.
Порт действительно блокируется на вход, и сессии все уничтожаются - тут вопросов нет.
Однако web-сервер в таком случае не закрывает соединение, и пытается доотправить данные клиенту (или просто происходит TCP retransmit, что не суть важно).
При этом побочно создается новая _исходящая_ сессия к браузеру, через который он все-таки умудряется пролезать и продолжать работать - из-за HTTP Keepalive сессии у браузера тоже завершаются не мгновенно.
Поскольку сессия получается "исходящей", она не блокируется по условию и не очищается.
Всем спасибо за репорты, в следующих релизах будет исправлено.
 
Прямо сейчас это неактуально для ботов, потому что большинство из них закрывают TCP-сессию при отлупе, а это обрывает соединение.

У вас только Virtual IP сервер, это другое - он работать не будет. Вам нужен L2TP/IPsec.

В следующей сборке будет поправлена реакция на смену префикса IPv6.

Да, это не ошибка, просто ocsp stapling не работает (в данном случае из-за dns).
Раньше его не было, в 3.0 он появился.

Поправлено в 3.00.A.1.0-3.

Уже была такая тема.
digest работает, если заходить по my.keenetic.net (строго по этому адресу).

Вы же сами разрешили доступ из Интернет в настройках. А гостевая сеть в данном понимании тоже является "Интернетом". Вот и результат.

Она всегда добавлялась, начиная с 2.08. Это нормальное поведение.
А если еще и руками хост зарегистрируете, то он тоже сам появится здесь.

Обе ошибки поправлены, спасибо за репорт.

Поправлено.

Всем спасибо, поправлено, версия 2.12.A.2.0-0.