Ну не во всех регионах) У нас даже разговоров об этом не слышно. Хотя уже хочется попробовать IPv6

Какой патч лучше использовать для ядра 3.13? v3.14.2.diff или v3.12.7.diff ?

Да там разницы особой нет - главное чтобе без режектов.

IMHO 3.12.7 должен подойти.

В чем смысл использовать временную EOL ветку ?

В бубунте это последняя в данный момент версия. Хочется попробовать ядро с их патчами.

Прошу прощения за глупый вопрос, но где указывается bt_hash_size ?

это параметр модуля

«modprobe xt_ndpi bt_hash_size=2 bt_hash_timeout=3600»

Спс. По поводу обнаружения bitorrent... Стоит rtorrent с параметрами шифрования

protocol.encryption.set = allow_incoming,try_outgoing,require,enable_retry,prefer_plaintext 

Новая сборка обнаруживает кажется все 100% p2p трафика! Приятно удивлен. Спасибо. Сегодня еще с виндовым utorrent протестирую и отпишусь

За 12 часов тестирования суммарно bittorrent трафика было на 258 Gb. Всего же трафика было 263. Неопределенного из них получается 5 Gb. И то не факт, ведь http и прочий трафик не детектировал, проверял только p2p. ТО есть получается менее 2% трафика не определенно. Результат думаю более чем отличный! =) Хэш еще не включал.

Коллеги супер , а можете сказать максимум на скольки pps в секунду это делалось?

Максимум что у меня бывает - 7kpps. Без каких либо проблем на слабеньком E-350. Уверен намного больше может, но у меня такого трафика нет.

Небольшое замечание. Правила iptables должны быть добавлены ДО запуска bittorrent клиента. Иначе пропускается не малая часть трафика. Или можно сбросить все текущие соединения с помощью conntrack -F после добавления правил.

Забыл спросить. У меня ядро собрано с CONFIG_NO_HZ=y. Вроде все работает. Есть ли смысл/необходимость собирать с CONFIG_HZ_PERIODIC=y и что это даст ?

Если в «head -1 /proc/net/xt_ndpi/info» gc не 0 (после того как пройдет время > timeout), то значит все нормально работает.

Все нормально, там 4476013

Замечательно!

Значит это предупреждение можно убрать.

Найден баг! патч выложен. Почему оно не роняло ядро - непонятно.

у меня вчера 2 раза рабочий шлюз роняло буквально через 2-23 секунды, после применения правил iptables с ndpi. Пока не выяснил полностью причину (ndpi ли вообще) не хотел лишний раз наговаривать. Но раз Вы подтверждаете, наверняка это оно, так как на старой сборке я этого не встречал.

Спасибо за патч, завтра по новой попробую собрать.

Проблема должна была проявляться только с bittorrent при включеном bt_hash_size и только после истечения таймаута.

Тут в лоровской вики есть статейка как ловить корки ядра. Я там дописывал про ramoops. Сам им пользуюсь.

ramoops

Вот как раз с bittorrent и была проблема) Только его и включал. Но вот хэш не припомню что включал... Вроде бы только xt__ndpi подгружал, без параметров.

И еще просьба. Патчи для imq (когда появляются для свежих ядер) добавлять в общий архив, если не сложно =). А то про linux-imqmq-3.17.3.patch узнал случайно, методом тыка.

Обновил инструкцию для убунтоводов. Теперь для ядра 3.17.

Я сейчас запустил на тестирование вариант с ipv4 & ipv6 на одном ядре (без rps).

Попутно обнаружил несколько мелких ошибок (не фатальных как до этого).

Если за 3-4 дня не будет странностей, то выложу обновления.

Я пока _вообще_ не тестировал 64-битную сборку.

Не могу решить задачку - делать сборку по умолчанию с IPv6 или без. В нынешнем варианте оно потребляет лишние ресурсы (память) и совсем чуть-чуть процессор. Возможно есть смысл не делать разные варианты сборки, а переделать модуль так, чтобы ресурсы потреблялись только если используется ipv6

Из интересных наблюдений - есть неизвестный udp трафик, который по общим характеристикам является шифрованными туннелями (похоже на openvpn). Его можно обнаруживать только статистиикой :(

На графиках добавилась страничка net7a для ipv6 и для net7* отдельно графики для tcp-syn

Лучше ipv6 включать флагом при сборке. Мало у кого он предвидеться в ближайшем будущем, а ресурсы лишние тратить не хочется...

И еще. В первом посте Вы говорили о возможности отключать ненужные протоколы. Очень бы это пригодилось, так как на текущие момент я использую максимум 5-7 протоколов. Не предвидеться такой возможности?

Я рассматривал такую возможность. IMHO это должно быть не очень сложно т.к. часть кода использует условную компиляцию.

Но есть подозрение, что это сильно усложнит поддержку кода т.к. любой merge c nDPI будет давать кучу режектов. Есть конечно вариант решения этой проблемы - попытаться свои изменения пропихнуть в официальную ветку.

А где можно графики с рабочей машинки посмотреть?

https://nagios.guap.ru/ndpi/

Спасибо.

Сегодня с 10:20 усложнил условия тестирования - сделал частоту всех ядер 1.6ГГц (вместо 3.2).

На cpu2 этот момент виден - на ядерные процессы это пока сильно не сказалось, в отличии от userspace!

Время для хеша BT - 1 час.

К сожалению баг все еще есть. Но bittorrent не причем. Включен был первый попавшийся протокол, в данном случае rtp. Проблема появляется после добавлений одного из правил iptables (еще не успел выяснить какого)

iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 25 -j CONNMARK --save-mark
iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 25 -j RETURN

Не успею сегодня проверить, падает ли ядро если xt_ndpi загружен или модуль не причем (рабочий день начался, экспериментировать не могу, офис паникует =) )

Дома с почти тем же ядром все нормально. Системы почти идентичные. Разве что на рабочей машине x64

ramoops еще не успел прикрутить. Есть только скрин монитора с последними сообщения (качество плохое правда). Если интересно могу выложить.

x64 я пока не тестил, но есть где проверить. Сегодня посмотрю.

Как настроить ramoops и скрипт для получения корки - вылолжил.

Выложил обновления, запустил тестирование на x86_64.

Существенное увеличение расходов памяти на flow (x86 - 1616 байт, x86_64 - 2816 байт )

Нет в планах отдельно 32 и 64 делать? Или игра не стоит свеч?

нет. Просто все указатели стали вместо 4 байт - 8.

Я несколько раз наступал на грабли, когда после применения патча к ядру я либо забывал перезагрузиться либо забывал обновить ядро и перезагружался с неисправленным ядром.

Результат один - корка при использовании нового модуля.

Не. Я после применений патчей собираю deb, ставлю и перезагружаюсь. Потом уже проверяю.

Если снова упадет, то корку (в любом виде) и xt_ndpi.ko отправь мне на vel21ripn собака gmail точка com

Завтра утром буду проверять последнюю сборку.

Новая сборка собралась без проблем и работает. Пока не падает (раньше сразу при применении правил падало ядро). Bittorrent включен. Сегодня на работе буду тестировать. P2P отлавливает нормально.

Вопрос. Как правильно смотреть объем памяти, который уходит на все это?

после загрузки модуля в логах видно:

sizeof hash_ip4p_node 44 - размер ноды bt-хеша

нужно умножать на count из /proc/net/xt_ndpi/info

sizeof id_struct 280 - размер node_id

нужно умножать на /sys/module/xt_ndpi/parameters/id_num или смотреть в /proc/slabinfo ndpi_ids

sizeof flow_struct 2816 - размер flow

нужно умножать на /proc/sys/net/netfilter/nf_conntrack_count или смотреть в slabinfo ndpi_flows

Тут откликнулся чел с ntop.org и рассказал, что самое неприятное - это патч ядра и что он знает как обойтись без него (странно, но он при этом даже не посмотрел какие я сделал исправления). Ждем его ответа на мое письмо...

Я тут еще раз внимательно посмотрел на nf_conntrack и понял, что похоже есть решение без патча ядра и без потерь производительности. Нужны 2 вещи: хнанение нескольких слов с conntrack и отслеживание закрытия conntrack.

Для реализации первой части придется принести в жертву nf_conntrack_labels, использование которого очень редко. Вторую часть можно взять из ipt_NETFLOW. Оно конечно хак, но не очень страшный.

А чем патч ядра плох?

тем, что это нужно делать.

Для ванильного ядра это не проблема, а для всяких RH/Oracle/SuSe/... пересборка ядра не столь проста и доступна.

Жаль, что с 2.6.2х убили поддержку цепочки нотифаев в conntrack...

IMHO Без патча ядра nDPI будет еще более привлекателен.

Началось тестирование версии не требующей патча ядра.

Главное требование к ядру

CONFIG_NF_CONNTRACK=y|m
CONFIG_NF_CONNTRACK_LABELS=y

и версия не ниже 3.4 ( возможно 3.2 )

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

Спасибо. Будем ждать!

По ресурсоемкости большая разница у новой сборки?

нет разницы.

А вот с версиями ядра я поторопился. С 3.9 возможно без патча ядра, а все до него нужно патчить. Можно моим патчем, а можно бекпортом labels extensions.

Но ниже 3.2 похоже уже точно не будет работать.

Luca Deri из ntop.org Наконец откликнулся на мое третье письмо и обещал в течениие недели внимательно посмотреть патчи.

А где она?

Что-то потерялась инструкция. Видел ее прежнюю версию, начал по ней делать, а потом раз! и ничего не стало.

Время от времени обновляется. Старую убрал, потому что есть новая. http://a7lanov.blogspot.ru/2014/10/ubuntu-imq-ndpi-07122014.html

Скоро vel выложит новую версию. После инструкцию тоже обновлю.

Благодарю! Но не пойму, почему я сам не смог ее найти ???

vel пишет, что в новой версии нет необходимости патчить ядро, начиная с 3.9. На ЭТУ версию нет инструкции пока?