LINUX.ORG.RU
Форум — General  

nDPI как замена l7filter

 ,


23

17

Если кому интересно, то вот рецепт

На большом потоке ( >300мбит/с ) c большим числом протоколов (>20) используется примерно 40% одного ядра Intel(R) Xeon(R) CPU E31230@3.20GHz. Если поток больше или процессор слабее, то включаем RPS или используем сетевые карты с multi-queue и irq-affinity :)

Требуется много памяти. На каждое соединение расходуется примерно 800+264*0.7 байт.

Исходники теперь есть на https://github.com/vel21ripn/nDPI/tree/netfilter

★★★★★

Последнее исправление: vel (всего исправлений: 3)
← Загрузка CPU после обновления
bttv automute option →
  1 2 3 4 5 6 7 8 9 10 11 12
Ответ на: комментарий от vel

Тогда поправьте мануал) Там указано что CONFIG_NF_CONNTRACK_NDPI надо включать. Вчера много времени потратил в поисках его. Думал «то ли лыжи не едут, то ли я ... ».

as_lan ★★
()
Ответ на: комментарий от aksenk

Это мой мануал). Разбираться в этом сейчас смысла нет. Он не актуален. Сегодня собрал новое ядром и модуль по новой инструкции Vel. Вечером проверю как работает ( сейчас как то не хочется домашний шлюз ребутить и рисковать потерей связи) и потом обновлю мануал.

as_lan ★★
()
Ответ на: комментарий от vel

Вы ошиблись. IMQ на 3.14 вызывает кернел паник. на 3.12.4 вроде как все нормально проходит. Весь день потерял сегодня, не мог понять, почему при включении imq терял доступ к шлюзу. Подключил монитор и увидел, как только включаю шейпер выдает кучу сообщений. буду обратно на 12.4 делать.

as_lan ★★
()
Ответ на: комментарий от as_lan

У меня не падает на 3.14.5 c imq 3.13.3

imq патч изменяет размеры skb, если не пересобрать модули, то обычно наступает oops

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Странно. В свободное время еще раз попробую. Я собирал на 3.14.6 (из-за того что он отмечен как стабильное). Может поэтому.

as_lan ★★
()
Ответ на: комментарий от as_lan

гм. я и не знал, что они переехали на github. До этого у них все было по-другому. imq-3.13.3 чуть-чуть отличается от того, что на гитхабе. Я его из из mailing-list брал еще в феврале. вот этот

vel ★★★★★
() автор топика
Ответ на: комментарий от as_lan

Я скорее всего завтра выложу переделанную версию. Что изменено кардинально: отключен ipv6, уменьшено число структур для строк с 200 до 64. Это дает не более 1632+2*236=2104 байт на поток (CT) вместо 3820+2*256 байт.

Вроде должны определятся не udp/tcp протоколы.

Запрет на обработку нелинейных skb > mtu.

Базируется все на версии SVN r7740

Патчи для ядер не именились.

Сейчас запустил тестироваться вариант с таким набором протоколов 

16131080 11310102311            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* t_udp */
31509061 40368197010            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* t_tcp */
47835004 51696248871            all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* total */
31968674 38056776258            all  --  *      *       0.0.0.0/0            0.0.0.0/0            protocols ftp_control,mail_pop,mail_smtp,mail_imap,dns,http,ntp,snmp,dhcp,mail_pops,directconnect,mail_smtps,edonkey,bittorrent,move,mail_imaps,shoutcast,sopcast,ssl_no_cert,msn,steam,ip_ipsec,rtp,rdp,vnc,ssl,ssh,sip,pptp,dropbox,skype,http_connect,http_proxy,viber,teamviewer,openvpn,ciscovpn,tor,rtcp,rsync,socks5,socks4,ftp_data
19100409 26869747505            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol http
 2247670 2404864183            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol bittorrent
 7113703 5379640015            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol bittorrent
 2570231 3140169460            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ssl
     328    17099            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol edonkey
     116     6750            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol edonkey
    4025   744606            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol dropbox
       1       40            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ftp_control
     778   220142            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ftp_data
     505    42571            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol mail_pop
     264    16622            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol mail_imap
    2632   654552            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol mail_smtp
     106    11141            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol mail_pops
     254    49123            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol mail_smtps
    1575   455667            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol mail_imaps
     275    20900            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ntp
     111    12042            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol dns
   66866 17593566            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol dns
       3      128            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ssh
     594    66400            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol pptp
      21     1004            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol openvpn
      16      815            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol openvpn
     324   107542            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_ipsec
       5      248            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ciscovpn
   39862  2081420            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ciscovpn
  180592 96114043            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol rtcp
   32868  6885156            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol rtp
   58235  9503808            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol skype
  360929 72452153            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol skype
      12      584            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol msn
       9      366            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol steam
   23083  6386168            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol steam
     264    67129            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol sip
     524   272348            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol sip
    6731  1819022            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol http_proxy
   18237  7502884            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol viber
     691   744232            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol socks5
      65     3180            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol socks5
     698    31176            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol vnc
    4358   451575            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol rdp
     252    61774            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol teamviewer
   59663 29096659            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol teamviewer
      31    10687            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol tor
 6175472 6210939141            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol unknown /* u_tcp */
 8232242 5691759131            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol unknown /* u_udp */

vel ★★★★★
() автор топика
Ответ на: комментарий от vel 
Jun 11 19:08:34 server kernel: [43053.613233] x_tables: ip_tables: ndpi.0 match: invalid size 36 (kernel) != (user) 28
Jun 11 19:08:34 server kernel: [43053.626416] x_tables: ip_tables: ndpi.0 match: invalid size 36 (kernel) != (user) 28
Jun 11 19:08:34 server kernel: [43053.629635] x_tables: ip_tables: ndpi.0 match: invalid size 36 (kernel) != (user) 28
Jun 11 19:08:34 server kernel: [43053.635578] x_tables: ip_tables: ndpi.0 match: invalid size 36 (kernel) != (user) 28
Jun 11 19:08:49 server kernel: [43068.239780] x_tables: ip_tables: ndpi.0 match: invalid size 36 (kernel) != (user) 28

Опять не так ядро собрал?

as_lan ★★
()
Ответ на: комментарий от aksenk

Попробуйте по новой инструкции. Несколько раз проверил ее. У меня без проблем все было.

as_lan ★★
()
Ответ на: комментарий от vel

Вам удалось с помощью ndpi резать торренты? В офисе появилась необходимость сделать общедоступный WiFi, но при этом чтоб халявщики не забили его торрентами. на домашней машинке у меня ndpi не детектит весь трафик (только 10-15% от всего трафика). Или может я как то неправильно маркирую пакеты...

Делаю так 

iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING  -m ndpi --bittorrent -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -m mark --mark 1 -j CONNMARK --save-mark
iptables -t mangle -A PREROUTING -m mark --mark 1 -j DROP

но не помогает.

Закрывать все порты, кроме часто используемых не вариант. Так как было очень много случаев когда пользовались софтом, который работает по разным портам. Каждый раз отлавливать эти порты не дело.

as_lan ★★
()
Ответ на: комментарий от as_lan

При старте оно плохо детектит, после набора статистики ( через несколько часов) в среднем неопознанного трафика на прием 6%, на передачу 11-13%

Есть шифрованные bt :( Его оно не определяет.

Нужно какой-то инструмент для сбора неопознанного траффика. Я про такой пока не знаю.

А L7-filter все хорошо детектит ?

vel ★★★★★
() автор топика
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

l7-filter вроде не плохо детектил, но не помню как там с шифрованным было дело. Последние 2 дня не могу заставить работать его. Судя по логу маркировка есть. Но в iptables уже не вижу чтоб пакеты были маркированы. К тому же в свое время отказался от него из-за высокой нагрузки (сжирал 20-35 CPU). Зато неопределенный трафик тоже маркирует своей меткой.

as_lan ★★
()
Ответ на: комментарий от as_lan

Зато неопределенный трафик тоже маркирует своей меткой.

в смысле ? Неопределенный трафик и там и здесь «unknown»

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Второй момент, который стоит пояснить — маски специального вида. По сути, они позволяют проверить, лежит ли маркировка пакета в диапазоне от 16 до 31. Такая защита позволяет избежать обработки маркировок 0 (такую маркировку имеет локальный трафик, так как он не проходит процедуру анализа), 1 и 2 (эти значения маркировки, как уже было замечено выше, означают, что тип пакета не определен), а также 32 и выше (эти значения мы оставляем для других задач).

Взять отсюда http://ru.wikibooks.org/wiki/Iptables

Или я как то неправильно понял, что там имелось ввиду.

as_lan ★★
()
Ответ на: комментарий от as_lan

бр... гадость какая этот l7-userspace! Понятно почему он жрет сpu. Небось оно еще и без mmap работает...

ядерный l7filter давно уже допилили до рабочего состояния.

У ndpi сейчас нет разницы между «еще не определен протокол» и «неизвестный протокол». Для обычного применения оно особо ненужно, а вот для отладки скорее всего было бы полезно.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

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

Или у вас есть патчи под 3 ветки ядра? С удовольствием потестил бы. На юзерспейс версию плюнул, надоело возиться. Лог д7-filter говорит что промаркировал, а в iptables глухо. Инфы по юзерспейс версию тоже почти нет. Везде просто как его ставить, и нигде про решение проблем.

as_lan ★★
()
Ответ на: комментарий от vel

Пардон за назойливость, но чем отличается netfilter_layer7_match.patch от netfilter_layer7_pktmatch.patch и какой ставить (2 других патча я так понимаю под старые ядра)

as_lan ★★
()
Ответ на: комментарий от as_lan

как минимум нужно 

600-netfilter_layer7_2.22.patch
601-netfilter_layer7_pktmatch.patch
602-netfilter_layer7_match.patch
603-netfilter_layer7_2.6.36_fix.patch

у меня работает это + это

на 3.14+

vel ★★★★★
() автор топика
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от as_lan

нет. Мой первый патч это все из openwrt, а вторая моя правка - чтоб с 3.14 работать. Патч из openwrt я брал когда openwrt было на 3.8.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

оК! Сегодня попробую с первым патчем собрать на 3.12

as_lan ★★
()
Ответ на: комментарий от vel

Видимо придется на 14 все собирать)

1.После применения первого Вашего патча пункт, связанный с layer7, так и не появился.

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

Hunk #1 FAILED at 1164.
1 out of 1 hunk FAILED -- saving rejects to file net/netfilter/Kconfig.rej
can't find file to patch at input line 19
3. Патчи из опенврт для 12 ветки. Аналогично первому пункту. Встали, но layer7 нигде нет.

as_lan ★★
()
Ответ на: комментарий от as_lan

Все правильно. C 3.12 немного изменились Kconfig и без правок оно не появляется. Приложи вручную части патча. Там не сложно.

Если второй патч не прикладывается с 19 строки, значит и первый не приложился (нет файла net/netfilter/xt_layer7.c)

vel ★★★★★
() автор топика
Ответ на: комментарий от as_lan

не, тоже из openwrt для 1.4.19

package/network/utils/iptables/patches/002-layer7_2.22.patch

но очень похоже, что там нет изменений.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Видимо у меня плохая аура. 

make  all-recursive
make[1]: Entering directory `/usr/src/iptables-1.4.12'
Making all in extensions
make[2]: Entering directory `/usr/src/iptables-1.4.12/extensions'
  CC       libxt_AUDIT.oo
In file included from /usr/include/linux/posix_types.h:4:0,
                 from ../include/linux/types.h:8,
                 from ../include/xtables.h:17,
                 from libxt_AUDIT.c:10:
/usr/src/linux/include/linux/stddef.h:11:2: error: expected identifier before numeric constant
make[2]: *** [libxt_AUDIT.oo] Error 1
make[2]: Leaving directory `/usr/src/iptables-1.4.12/extensions'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/iptables-1.4.12'
make: *** [all] Error 2
as_lan ★★
()
Ответ на: комментарий от as_lan

А ядро то какое ? iptables-1.4.12 это же старье!

iptables заявляет, что его можно собирать без ядра, но на практике без инклюдов от ядра оно не собирается ( т.е. нужно «make headers_install» после сборки ядра и скопировать их в систему )

Я обычно собираю ядро в отдельный каталог и в этом случае iptables не собирается без "--with-kbuild="

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

ядро как и у вас 3,14,5

1,4,12 для бубунты 12,04 последний. При попытке собрать из исходников 1,4,19 целя простыня ошибок выпала. Хидеры от своего 3,14 стоят. Лежат в /usr/src/linux-headers-3.14.5-v-ndpi+imq+l7

iptables пытался собрать так 

./configure --with-ksource=/usr/src/linux-3.14.5
make
после make в итоге такая ошибка.

as_lan ★★
()
Ответ на: комментарий от as_lan

"--with-ksource=" на сколько я помню особой пользы не дают, в отличии от "--with-kbuild="

1.4.12 - это пипец! Оно вышло 3 года назад! За это время в iptables было много изменений. IMHO для ядер 3.14 только iptables-1.4.21

Я обычно собираю ядро так: 2 каталога рядом - в каталоге linux лежат исходники ядра, в каталоге obj - конфиг ядра и туда же оно собирается.

cd linux
OBJ=`(cd ../obj; pwd)`
make oldconfig O=$OBJ
make -j5 O=$OBJ
make headers_install O=$OBJ
(cd $OBJ && tar -zcf kernel-headers.tar.gz --exclude ..install.cmd --exclude .install usr/include )

полученный архив распаковывается в корень

дальше можно собирать iptables & ipset & xtables-addons

IMQ,NDPI,L7 изменяют структуру sk_buff! Чтобы правильно собирать внешние ядерные модули нужно либо ядерные хидеры установить в систему ( скопировать ) либо всему собираемому софту указывать путь к исходникам ядра и каталогу куда ядро собирали.

У меня сильно патченная версия iptables т.к. оригинал очень геморройно собирать с патченными ядрами. В оригинальной версии продублированы все ядреные хидеры и часть изменений в ядре требует изменений этих дублей в iptables. Я сделал просто - похерил все дубли в iptables и теперь оно зависит от ядра, но при этом собирается правильно.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Собрать ndpi оказалось в разы легче чем этот l7)

Столько телодвижений, а стоит оно того? Он хотя бы детектит как ndpi или лучше? Как минимум bittorrent. Так как если он детектит не лучше то я вообще не вижу смысла с ним играться.

as_lan ★★
()
Ответ на: комментарий от as_lan

Из серии p2p в l7filter знает про 

100bao.pat:# Protocol groups: p2p
applejuice.pat:# Protocol groups: p2p
ares.pat:# Protocol groups: p2p open_source
bittorrent.pat:# Protocol groups: p2p open_source
directconnect.pat:# Protocol groups: p2p
edonkey.pat:# Protocol groups: p2p
fasttrack.pat:# Protocol groups: p2p
freenet.pat:# Protocol groups: p2p document_retrieval open_source
gnucleuslan.pat:# Protocol groups: p2p open_source
gnutella.pat:# Protocol groups: p2p open_source
goboogy.pat:# Protocol groups: p2p
hotline.pat:# Protocol groups: p2p
imesh.pat:# Protocol groups: p2p
kugoo.pat:# Protocol groups: p2p
mute.pat:# Protocol groups: p2p open_source
napster.pat:# Protocol groups: p2p
openft.pat:# Protocol groups: p2p open_source
poco.pat:# Protocol groups: p2p
pplive.pat:# Protocol groups: p2p streaming_video proprietary
skypeout.pat:# Protocol groups: voip p2p proprietary
skypetoskype.pat:# Protocol groups: voip p2p proprietary
soribada.pat:# Protocol groups: p2p
soulseek.pat:# Protocol groups: p2p
tesla.pat:# Protocol groups: p2p
thecircle.pat:# Protocol groups: p2p open_source
xunlei.pat:# Protocol groups: p2p
IMHO это нешифрованные p2p

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

А с шифрованным udp вообще непонятно что делать.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

В итоге я остановился на ndpi+iptables+tc. На шлюзе стоит rtorrent, отключил шифрование полностью, ndpi таким образом p2p входящий полностью видит и метки ставит(по крайней мере по статистике видно что 99,9% трафика распознается). Исходящий маркирую по uid пользователя, от которого запущен rtorrent (создал отдельную учетку). В остальном вся связка отлично работает.

Если же придется по тем или иным причинам включить шифрование, то буду отдавать минимальный приоритет трафику самого шлюза (ну разве что http, ssh и т.п. буду в другой приоритет кидать), а транзитному более высокий.

Сам ndpi вроде работает стабильно. Уже недели 3 без проблем работает.

И вопрос. Можно ли с Вашими патчами собирать более новые версии ndpi, когда они появятся в svn? Или каждый раз нужно будет патчи обновлять? (при условии что ядро останется тем же)

as_lan ★★
()
Ответ на: комментарий от as_lan

Текущий ядерный патч никак не связан с 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 нет проблем с доступностью памяти.

vel ★★★★★
() автор топика
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от as_lan

мда. Пришла беда откуда ее не ждали.

Тут придется заниматься торрентам. Я уже вижу, что даже нешифрованные пакеты nDPI не видит, хотя они очень специфические.

Надеюсь через пару недель будут результаты.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

У меня нешифрованный вроде как нормально видит. Как минимум отдачу, потому что входящий торрент немного иначе маркирую.

as_lan ★★
()
Ответ на: комментарий от as_lan

Возможно есть смысл разделить классификацию трафика торрентов на трафик между пирами и трафик с трекерами.

Я тут сталкнулся с задачей найти в сети машину раздающую торрент с заданым хешем. Выяснилось, что анонсы обнаруживаются легко, но ndpi их считает неизвестным трафиком.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

FATAL: Error inserting xt_ndpi (/lib/modules/3.11.10-17-desktop/extra/xt_ndpi.ko): Unknown symbol in module, or unknown parameter (see dmesg)

xt_ndpi: Unknown symbol ndpi_search_twitter (err 0) xt_ndpi: Unknown symbol ndpi_search_ftp_data (err 0) xt_ndpi: Unknown symbol ndpi_search_pando (err 0) xt_ndpi: Unknown symbol ndpi_search_zmq (err 0) xt_ndpi: Unknown symbol ndpi_search_redis (err 0) xt_ndpi: Unknown symbol ndpi_search_ayiya (err 0) xt_ndpi: Unknown symbol ndpi_search_ftp_control (err 0) xt_ndpi: Unknown symbol ndpi_search_megaco (err 0) xt_ndpi: Unknown symbol ndpi_search_rtmp (err 0)

Чудом собрал nDPI на OpenSuse 13.1 с ядром 3.11.10 и вот такая беда. Подскажите, пожалуйста, в чем трабл и как решить =(

anonymous
()
Ответ на: комментарий от anonymous

в nDPI-1.4.0.r7740.tar.gz уже все патченное, кроме ядра.

С ядерной поддержкой у них (в nDPI) не все хорошо. Часть новых коммтов делают невозможным сборку для ядра.

поддержка твиттера полный говнокод! 4 идентичных фрагмента с разными сетями 

    // 192.133.76.0/22
    /* 192.133.76.0 - 192.133.79.255 */
    if(((src >= 3229961216ul) && (src <= 3229962239ul))
       || ((dst >= 3229961216ul) && (dst <= 3229962239ul))
       || ((src & 0xFFFFFC00 /* 255.255.252.0  */) == 0x5C854C00/* 92.133.76.0 */)
       || ((dst & 0xFFFFFC00 /* 255.255.252.0  */) == 0x5C854C00/* 92.133.76.0 */)
       ) {
      ndpi_int_twitter_add_connection(ndpi_struct, flow);
      return;
    }

чуть позже выложу обновленный до r7867 вариант

vel ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8 9 10 11 12
← Загрузка CPU после обновления
General
bttv automute option →