История изменений

Текущий ядерный патч никак не связан с ndpi. Это просто небольшое расширение возможностей nf_conntrack_extend.

Проблема появится в случае добавления нового протокола и в случае революционных изменений API nDPI.

Если в nDPI появляется новый протокол, то его нужно добавить в ndpi-netfilter/src/Makefile аналогично другим протоколам и сказать «make src/xt_ndpi.h» в ndpi-netfilter

ndpi-netfilter/ipt зависит только от ndpi-netfilter/src/xt_ndpi.h

ndpi-netfilter/src зависит и от ndpi-netfilter/src/xt_ndpi.h и от nDPI

У меня есть git для nDPI - git://lms.guap.ru/nDPI, но комменты к коммитам убогие.

Есть memory leak - 8 байт при каждой выгрузке модуля xt_ndpi.ko . Где - не знаю и искать лень!

О чем нужно знать: udp приходит дефрагментированное на уровне IPv4, но skb при этом может быть фрагментированный (я видел до ~7 кб пакеты с 5-ю фрагментами и skb ~1.5kb 3 фрагмента)! Я добавил в в xt_ndpi параметер mtu - он ограничивает размер skb которые будут линеаризироваться (это дополнительные временные расходы памяти). Если skb фрагментированный и его длина больше параметра mtu, то он тупо отбрасывается. IMHO mtu можно поднять до 4000 ( чтоб помещался в страницу ). Кстати, эта проблема есть и в l7filter. При нехватке памяти это убивает систему!

Настоятельно рекомендую не пытаться проверять пакеты которые имеют состояние INVALID или UNTRACKED в conntrack! Т.е.

iptables ..... -m conntrack ! --ctstate INVALID,UNTRACKED -m ndpi ....

Все параметры можно посмотреть через

grep -a . /sys/module/xt_ndpi/parameters/*

Из интересных

• jumbo - фрагментированных skb длиной >mtu
• skb_lin - обработанно не фрагментированных skb
• skb_sgo - обработанно фрагментированных skb (т.е. с skb_clone)
• zpl* - parsed lines - статистика по числу распознанных текстовых строк в пакете (в структуре flow есть двойной набор указателей на найденные строки и это самая длинная часть flow! в оригинале их было 200, но по моей статистике больше 70 строк было найдено всего 2-3 раза за неделю и сократив их до 64 я уменьшил структуру flow с 3800 байт до 1632).

  zpl010 - < 10 в пакете

  ...

  zpl080 - < 80 в пакете (уже не может быть )

  zpl100x - > 100

• max_parsed_l - максимальное число распознанных строк

остальные параметры - отладочные счетчики разных событий (упешных или не успешных).

PS я примерно 5-6 дней тестировал на x86_64. Работает стабильно, но расходы памяти не радуют - 2816 байт на flow против 1632 на x86. С другой стороны на x86_64 нет проблем с доступностью памяти.

Текущий ядерный патч никак не связан с ndpi. Это просто небольшое расширение возможностей nf_conntrack_extend.

Проблема появится в случае добавления нового протокола и в случае революционных изменений API nDPI.

Если в nDPI появляется новый протокол, то его нужно добавить в ndpi-netfilter/src/Makefile аналогично другим протоколам и сказать «make src/xt_ndpi.h» в ndpi-netfilter

ndpi-netfilter/ipt зависит только от ndpi-netfilter/src/xt_ndpi.h

ndpi-netfilter/src зависит и от ndpi-netfilter/src/xt_ndpi.h и от nDPI

У меня есть git для nDPI - git://lms.guap.ru/nDPI, но комменты к коммитам убогие.

Есть memory leak - 8 байт при каждой выгрузке модуля xt_ndpi.ko . Где - не знаю и искать лень!

О чем нужно знать: udp приходит дефрагментированное на уровне IPv4, но skb при этом может быть фрагментированный (я видел до ~7 кб пакеты)! Я добавил в в xt_ndpi параметер mtu - он ограничивает размер skb которые будут линеаризироваться (это дополнительные временные расходы памяти). Если skb фрагментированный и его длина больше параметра mtu, то он тупо отбрасывается. IMHO mtu можно поднять до 4000 ( чтоб помещался в страницу ). Кстати, эта проблема есть и в l7filter.

Настоятельно рекомендую не пытаться проверять пакеты которые имеют состояние INVALID или UNTRACKED в conntrack! Т.е.

iptables ..... -m conntrack ! --ctstate INVALID,UNTRACKED -m ndpi ....

Все параметры можно посмотреть через

grep -a . /sys/module/xt_ndpi/parameters/*

Из интересных

• jumbo - фрагментированных skb длиной >mtu
• skb_lin - обработанно не фрагментированных skb
• skb_sgo - обработанно фрагментированных skb (т.е. с skb_clone)
• zpl* - parsed lines - статистика по числу распознанных текстовых строк в пакете (в структуре flow есть двойной набор указателей на найденные строки и это самая длинная часть flow! в оригинале их было 200, но по моей статистике больше 70 строк было найдено всего 2-3 раза за неделю и сократив их до 64 я уменьшил структуру flow с 3800 байт до 1632).

  zpl010 - < 10 в пакете

  ...

  zpl080 - < 80 в пакете (уже не может быть )

  zpl100x - > 100

• max_parsed_l - максимальное число распознанных строк

остальные параметры - отладочные счетчики разных событий (упешных или не успешных).

PS я примерно 5-6 дней тестировал на x86_64. Работает стабильно, но расходы памяти не радуют - 2816 байт на flow против 1632 на x86. С другой стороны на x86_64 нет проблем с доступностью памяти.