Здравствуйте.
Наткнулся на проблему, описанную в upstream zapret2:
[bol-van/zapret2#229]
Суть проблемы: на Keenetic Giga KN-1011 с Mediatek при большом TLS ClientHello, который фрагментируется и становится больше MTU, nfqws начинает reasm, но он не завершается. В логах видно, что первый фрагмент около 1400 байт попадает в NFQUEUE и удерживается с сообщением вида:
DELAY desync until reasm is complete
А второй фрагмент, примерно 384 байта, в NFQUEUE уже не приходит. В итоге соединение рвётся после ретрансмиссий/RST. Временным обходом было использование --reasm-disable, но это отключает reasm и не выглядит правильным решением.
Автор issue позже написал, что проблема решилась после отключения PPE через CLI Keenetic:
(config)> no ppe
system configuration save
После этого оба фрагмента TLS ClientHello начинают нормально попадать в NFQUEUE, reasm работает, и --reasm-disable больше не нужен.
Возможно, стоит добавить это в README / раздел troubleshooting для Keenetic/Netcraze, например как отдельный пункт:
На некоторых Keenetic с Mediatek/PPE reasm может не работать: первый фрагмент TLS ClientHello попадает в NFQUEUE, а последующие фрагменты обходят очередь. Симптомы — не открываются отдельные домены с большим TLS ClientHello, в логах DELAY desync until reasm is complete, помогает --reasm-disable. Правильнее попробовать отключить PPE через CLI Keenetic:
no ppe
system configuration save
После этого перезапустить nfqws2-keenetic и проверить работу без --reasm-disable.
Также, если технически возможно, было бы полезно добавить предупреждение/проверку для Keenetic с включённым PPE, но даже упоминание в инструкции уже сильно поможет тем, кто столкнётся с такой же проблемой.
Здравствуйте.
Наткнулся на проблему, описанную в upstream zapret2:
[bol-van/zapret2#229]
Суть проблемы: на Keenetic Giga KN-1011 с Mediatek при большом TLS ClientHello, который фрагментируется и становится больше MTU,
nfqwsначинает reasm, но он не завершается. В логах видно, что первый фрагмент около 1400 байт попадает в NFQUEUE и удерживается с сообщением вида:А второй фрагмент, примерно 384 байта, в NFQUEUE уже не приходит. В итоге соединение рвётся после ретрансмиссий/RST. Временным обходом было использование
--reasm-disable, но это отключает reasm и не выглядит правильным решением.Автор issue позже написал, что проблема решилась после отключения PPE через CLI Keenetic:
После этого оба фрагмента TLS ClientHello начинают нормально попадать в NFQUEUE, reasm работает, и
--reasm-disableбольше не нужен.Возможно, стоит добавить это в README / раздел troubleshooting для Keenetic/Netcraze, например как отдельный пункт:
Также, если технически возможно, было бы полезно добавить предупреждение/проверку для Keenetic с включённым PPE, но даже упоминание в инструкции уже сильно поможет тем, кто столкнётся с такой же проблемой.