[devel] Потеря пакетов libpcap и как с этим бороться

[devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

Здравствуйте.

Думаю ни для кого не секрет, что при больших нагрузках libpcap теряет
много пакетов в результате чего вся статистика основанная на libpcap не
отвечает действительности.
Вот результаты некоторых исследований http://luca.ntop.org/Ring.pdf
Есть вариант решения проблемы - модуль pf_ring
(http://www.ntop.org/PF_RING.html ) Раньше было патчем к ядру, и т.к.
требовалось ядро патчить, то проблемно было включить этот патч.
Но с версии 4.X стало возможным собирать как модулем.

Поэтому хочется заиметь такой функционал в полном объеме.

Что для этого нужно:
1. Собрать дополнительный модуль к ядру
2. Собрать дополнительно пропатченные модули к поддерживаемым сетевухам
3. Собрать пропатченную версию libpcap
4. Пересобрать софт с новой libpcap


С пунктом первым у меня вопросов нет. Это просто.
Со вторым сложнее, т.к. имена модулей совпадают с теми что уже есть в ядре.
Отюда вопрос: есть ли возможность собирать модули с одинаковыми именами
и как обеспечить приоритет загрузки нужного модуля?

Пункт 3 тоже решаем. Или мы вносим данный функционал в текущий пакет
libpcap (который давно пора обновить) или придется делать второй пакет.
4 пункт решается аналогично третьему.

Хочется услышать мнение заинтересованных, если такие есть.
Стоит ли заморачиваться и реализовывать такое в репозитарии?

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3262 bytes --]

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Anton Farygin]

28.12.2009 19:41, Slava Dubrovskiy пишет:
> Здравствуйте.
>
> Думаю ни для кого не секрет, что при больших нагрузках libpcap теряет
> много пакетов в результате чего вся статистика основанная на libpcap не
> отвечает действительности.
> Вот результаты некоторых исследований http://luca.ntop.org/Ring.pdf
> Есть вариант решения проблемы - модуль pf_ring
> (http://www.ntop.org/PF_RING.html ) Раньше было патчем к ядру, и т.к.
> требовалось ядро патчить, то проблемно было включить этот патч.
> Но с версии 4.X стало возможным собирать как модулем.
>
> Поэтому хочется заиметь такой функционал в полном объеме.
>
> Что для этого нужно:
> 1. Собрать дополнительный модуль к ядру

Лучше включить в ядро.
> 2. Собрать дополнительно пропатченные модули к поддерживаемым сетевухам

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

> 3. Собрать пропатченную версию libpcap

Функционал в пакет libpcap.

> 4. Пересобрать софт с новой libpcap

аналогично

<skip>
>
> Хочется услышать мнение заинтересованных, если такие есть.
> Стоит ли заморачиваться и реализовывать такое в репозитарии?

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

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

28.12.2009 20:30, Anton Farygin пишет:
> 28.12.2009 19:41, Slava Dubrovskiy пишет:
>> Здравствуйте.
>>
>> Думаю ни для кого не секрет, что при больших нагрузках libpcap теряет
>> много пакетов в результате чего вся статистика основанная на libpcap не
>> отвечает действительности.
>> Вот результаты некоторых исследований http://luca.ntop.org/Ring.pdf
>> Есть вариант решения проблемы - модуль pf_ring
>> (http://www.ntop.org/PF_RING.html ) Раньше было патчем к ядру, и т.к.
>> требовалось ядро патчить, то проблемно было включить этот патч.
>> Но с версии 4.X стало возможным собирать как модулем.
>>
>> Поэтому хочется заиметь такой функционал в полном объеме.
>>
>> Что для этого нужно:
>> 1. Собрать дополнительный модуль к ядру
>
> Лучше включить в ядро.
Я тоже так думаю, но мантейнер ядра как я понял и так загружен. Проще
сделать отдельным модулем, чем ждать.
>> 2. Собрать дополнительно пропатченные модули к поддерживаемым сетевухам
> патчить надо модули в ядре.
Это было бы идеально, но опять же, я пару багов повесил на ядро - и
реакции ноль. Даже не assigned
> 3. Собрать пропатченную версию libpcap
> Функционал в пакет libpcap.

>
>> 4. Пересобрать софт с новой libpcap
>
> аналогично
>
> <skip>
>>
>> Хочется услышать мнение заинтересованных, если такие есть.
>> Стоит ли заморачиваться и реализовывать такое в репозитарии?
>
> думаю, что для подсчёта статистики лучше использовать другие
> инструменты, тем более что они есть.
Да, но очень много программ пользуют libpcap для показа статистики и
иногда это единственный возможный вариант.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3262 bytes --]

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Anton Farygin]

28.12.2009 22:35, Slava Dubrovskiy пишет:
> 28.12.2009 20:30, Anton Farygin пишет:
>> 28.12.2009 19:41, Slava Dubrovskiy пишет:
>>> Здравствуйте.
>>>
>>> Думаю ни для кого не секрет, что при больших нагрузках libpcap теряет
>>> много пакетов в результате чего вся статистика основанная на libpcap не
>>> отвечает действительности.
>>> Вот результаты некоторых исследований http://luca.ntop.org/Ring.pdf
>>> Есть вариант решения проблемы - модуль pf_ring
>>> (http://www.ntop.org/PF_RING.html ) Раньше было патчем к ядру, и т.к.
>>> требовалось ядро патчить, то проблемно было включить этот патч.
>>> Но с версии 4.X стало возможным собирать как модулем.
>>>
>>> Поэтому хочется заиметь такой функционал в полном объеме.
>>>
>>> Что для этого нужно:
>>> 1. Собрать дополнительный модуль к ядру
>>
>> Лучше включить в ядро.
> Я тоже так думаю, но мантейнер ядра как я понял и так загружен. Проще
> сделать отдельным модулем, чем ждать.

Отдельным модулем - не получится, ибо есть пункт 2.

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Sergey Y. Afonin]

On Monday 28 December 2009, Slava Dubrovskiy wrote:

> Хочется услышать мнение заинтересованных, если такие есть.
> Стоит ли заморачиваться и реализовывать такое в репозитарии?
 
мне бы было интересно.

А такой вариант если ? Дополнительное ядро с соответствующими изменениями,
дополнительный libpcap с provides libpcap и не трогать весь остальной софт ?

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Sergey Y. Afonin]

On Monday 28 December 2009, Anton Farygin wrote:

> думаю, что для подсчёта статистики лучше использовать другие 
> инструменты, тем более что они есть.
 
Кстати, а какие-то есть, чтобы не сильно переделывать завязанное
на libpcap ? И, если вдруг есть, сравнение производительности
методов бы...

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Sergey Bolshakov]

>>>>> "Sergey" == Sergey Y Afonin <asy-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > On Monday 28 December 2009, Anton Farygin wrote:
 >> думаю, что для подсчёта статистики лучше использовать другие 
 >> инструменты, тем более что они есть.
 
 > Кстати, а какие-то есть, чтобы не сильно переделывать завязанное
 > на libpcap ? И, если вдруг есть, сравнение производительности
 > методов бы...

Если под статистикой понимать netflow, есть куда менее интрузивный
ipt_netflow, затрагивающий лишь ядро и iptables.

-- 

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

28.12.2009 23:53, Anton Farygin пишет:
>>>> Что для этого нужно:
>>>> 1. Собрать дополнительный модуль к ядру
>>>
>>> Лучше включить в ядро.
>> Я тоже так думаю, но мантейнер ядра как я понял и так загружен. Проще
>> сделать отдельным модулем, чем ждать.
> Отдельным модулем - не получится, ибо есть пункт 2.
Получится. Модуль и так будет работать, без пропатченных драйверов
сетевух. Просто в режиме совместимости что немного хуже по
производительности, но лучше на порядки чем без него.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3262 bytes --]

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

29.12.2009 14:47, Sergey Bolshakov пишет:
> >> думаю, что для подсчёта статистики лучше использовать другие
>  >> инструменты, тем более что они есть.
>  
>  > Кстати, а какие-то есть, чтобы не сильно переделывать завязанное
>  > на libpcap ? И, если вдруг есть, сравнение производительности
>  > методов бы...
>
> Если под статистикой понимать netflow, есть куда менее интрузивный
> ipt_netflow, затрагивающий лишь ядро и iptables.
>   
Я понимаю не только как статистика. Да, для сбора статистики с
нескольких роутеров netflow не заменим. А для для таких программ как
tcpdump, wireshark и кучи другого, что запускается на сервере и
показывает трафик, он как пришей кобыле 5 колесо.

И кстати, вы сравнивали производительность iptables под большой нагрузкой?
Вот нагуглил, например, как загрузка модуля ip_conntrack влияет
http://archive.linuxvirtualserver.org/html/lvs-users/2001-12/msg00141.html
Правда может что-то с тех пор и поменялось, но как-то сомнительно.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3262 bytes --]

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Vladimir Lettiev]

29 декабря 2009 г. 17:25 пользователь Slava Dubrovskiy <slava@> написал:
> И кстати, вы сравнивали производительность iptables под большой нагрузкой?
> Вот нагуглил, например, как загрузка модуля ip_conntrack влияет
> http://archive.linuxvirtualserver.org/html/lvs-users/2001-12/msg00141.html
> Правда может что-то с тех пор и поменялось, но как-то сомнительно.

На самом деле conntrack не нужен, чтобы трафик считать на iptables.
По производительности netfilter нагуглилась интересная дока:
http://people.netfilter.org/kadlec/nftest.pdf

-- 
Vladimir Lettiev aka crux <theCrux@gmail.com>

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Alexey Shabalin]

28 декабря 2009 г. 19:41 пользователь Slava Dubrovskiy написал:
> Здравствуйте.
>
> Думаю ни для кого не секрет, что при больших нагрузках libpcap теряет
> много пакетов в результате чего вся статистика основанная на libpcap не
> отвечает действительности.
> Вот результаты некоторых исследований http://luca.ntop.org/Ring.pdf
> Есть вариант решения проблемы - модуль pf_ring
> (http://www.ntop.org/PF_RING.html ) Раньше было патчем к ядру, и т.к.
> требовалось ядро патчить, то проблемно было включить этот патч.
> Но с версии 4.X стало возможным собирать как модулем.
>
> Поэтому хочется заиметь такой функционал в полном объеме.
>
> Что для этого нужно:
> 1. Собрать дополнительный модуль к ядру
Есть ли подвижки в сборке модуля для ядра?

> 2. Собрать дополнительно пропатченные модули к поддерживаемым сетевухам
> 3. Собрать пропатченную версию libpcap
> 4. Пересобрать софт с новой libpcap

-- 
Alexey Shabalin

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Alexey Shabalin]

28 декабря 2009 г. 19:41 пользователь Slava Dubrovskiy
<slava@tangramltd.com> написал:
> Здравствуйте.
>
> Думаю ни для кого не секрет, что при больших нагрузках libpcap теряет
> много пакетов в результате чего вся статистика основанная на libpcap не
> отвечает действительности.
> Вот результаты некоторых исследований http://luca.ntop.org/Ring.pdf
> Есть вариант решения проблемы - модуль pf_ring
> (http://www.ntop.org/PF_RING.html ) Раньше было патчем к ядру, и т.к.
> требовалось ядро патчить, то проблемно было включить этот патч.
> Но с версии 4.X стало возможным собирать как модулем.
>
> Поэтому хочется заиметь такой функционал в полном объеме.
>
> Что для этого нужно:
> 1. Собрать дополнительный модуль к ядру
> 2. Собрать дополнительно пропатченные модули к поддерживаемым сетевухам
> 3. Собрать пропатченную версию libpcap
> 4. Пересобрать софт с новой libpcap
>
>
> С пунктом первым у меня вопросов нет. Это просто.

Первый пункт я сделал :) модуль ядра отправил в сизиф.

> Со вторым сложнее, т.к. имена модулей совпадают с теми что уже есть в ядре.
> Отюда вопрос: есть ли возможность собирать модули с одинаковыми именами
> и как обеспечить приоритет загрузки нужного модуля?

Этим займёмся позже.

>
> Пункт 3 тоже решаем. Или мы вносим данный функционал в текущий пакет
> libpcap (который давно пора обновить) или придется делать второй пакет.

я вот не совсем понял, будет ли пропатченный libpcap работать без
ядерного модуля.
Если будет то лучше обойтись единственным libpcap.
По ходу сборки userland для pf_ring возникают следующие вопросы:
1. нужен ли отдельный пакет libpfring? всё равно все используют только
libpcap. Может втянуть libpfring в libpcap?
2. в репо PF_RING смотрю на Makefile и вижу - libpcap-ring линкуется
со статической libpfring.a, зачем потом tcpdump и snort тоже линковать
с libfring.a. Надо это делать?
3. Или делать libpfring как shared? тогда надо soname добавлять.

> 4 пункт решается аналогично третьему.
> Хочется услышать мнение заинтересованных, если такие есть.
> Стоит ли заморачиваться и реализовывать такое в репозитарии?
>

-- 
Alexey Shabalin

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

18.02.2010 15:00, Alexey Shabalin пишет:
>> 1. Собрать дополнительный модуль к ядру
>> 2. Собрать дополнительно пропатченные модули к поддерживаемым сетевухам
>> 3. Собрать пропатченную версию libpcap
>> 4. Пересобрать софт с новой libpcap
>>
>>
>> С пунктом первым у меня вопросов нет. Это просто.
>>     
> Что для этого нужно:
> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>   
Ой, спасибо. Все руки не доходили...
>> Со вторым сложнее, т.к. имена модулей совпадают с теми что уже есть в ядре.
>> Отюда вопрос: есть ли возможность собирать модули с одинаковыми именами
>> и как обеспечить приоритет загрузки нужного модуля?
>>     
> Этим займёмся позже.
>   
>> Пункт 3 тоже решаем. Или мы вносим данный функционал в текущий пакет
>> libpcap (который давно пора обновить) или придется делать второй пакет.
>>     
> я вот не совсем понял, будет ли пропатченный libpcap работать без
> ядерного модуля.
> Если будет то лучше обойтись единственным libpcap.
>   
Будет.
> По ходу сборки userland для pf_ring возникают следующие вопросы:
> 1. нужен ли отдельный пакет libpfring? всё равно все используют только
> libpcap. Может втянуть libpfring в libpcap?
>   
Не знаю. Думаю логично сделать.
> 2. в репо PF_RING смотрю на Makefile и вижу - libpcap-ring линкуется
> со статической libpfring.a, зачем потом tcpdump и snort тоже линковать
> с libfring.a. Надо это делать?
>   
Я бы делал shared
> 3. Или делать libpfring как shared? тогда надо soname добавлять.
>   
Да, кажется это правильнее.

-- 
WBR,
Dubrovskiy Vyacheslav

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Michael Shigorin]

On Thu, Feb 18, 2010 at 04:00:23PM +0300, Alexey Shabalin wrote:
> По ходу сборки userland для pf_ring возникают следующие вопросы:
> 1. нужен ли отдельный пакет libpfring? всё равно все используют
> только libpcap. Может втянуть libpfring в libpcap?

А если обновится что-то одно?  IMHO лучше разные апстримы держать
в разных пакетах.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Alexey Shabalin]

18 февраля 2010 г. 17:14 пользователь Slava Dubrovskiy написал:
> 18.02.2010 15:00, Alexey Shabalin пишет:
>>> 1. Собрать дополнительный модуль к ядру
>>> 2. Собрать дополнительно пропатченные модули к поддерживаемым сетевухам
>>> 3. Собрать пропатченную версию libpcap
>>> 4. Пересобрать софт с новой libpcap
>>>
>>>
>>> С пунктом первым у меня вопросов нет. Это просто.
>>>
>> Что для этого нужно:
>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>>
> Ой, спасибо. Все руки не доходили...
>>> Со вторым сложнее, т.к. имена модулей совпадают с теми что уже есть в ядре.
>>> Отюда вопрос: есть ли возможность собирать модули с одинаковыми именами
>>> и как обеспечить приоритет загрузки нужного модуля?
>>>
>> Этим займёмся позже.
>>
>>> Пункт 3 тоже решаем. Или мы вносим данный функционал в текущий пакет
>>> libpcap (который давно пора обновить) или придется делать второй пакет.
>>>
>> я вот не совсем понял, будет ли пропатченный libpcap работать без
>> ядерного модуля.
>> Если будет то лучше обойтись единственным libpcap.
>>
> Будет.
>> По ходу сборки userland для pf_ring возникают следующие вопросы:
>> 1. нужен ли отдельный пакет libpfring? всё равно все используют только
>> libpcap. Может втянуть libpfring в libpcap?
>>
> Не знаю. Думаю логично сделать.
>> 2. в репо PF_RING смотрю на Makefile и вижу - libpcap-ring линкуется
>> со статической libpfring.a, зачем потом tcpdump и snort тоже линковать
>> с libfring.a. Надо это делать?
>>
> Я бы делал shared
>> 3. Или делать libpfring как shared? тогда надо soname добавлять.
>>
> Да, кажется это правильнее.

libpfring отправлен в сизиф.
libpcap с поддержкой libpfring у меня в git. Прошу посмотреть, не
слишком ли я его испохабил.
Осталось протолкнуть его в сизиф и пересобрать кучу пакетов.

-- 
Alexey Shabalin

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

18.02.2010 15:00, Alexey Shabalin пишет:
>
>> 1. Собрать дополнительный модуль к ядру
>>     
> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>   
Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
При попытке выполнить
[root@dubrhost slava]# modprobe
pf_ring                                                                
Убито                                                                                                  


И в dmesg при этом:

[  468.643289] [PF_RING] Welcome to PF_RING 4.1.3 ($Revision: $)
[  468.643291] (C) 2004-10 L.Deri <deri@ntop.org>
[  468.643307] [PF_RING] registered /proc/net/pf_ring/
[  468.643310] NET: Registered protocol family 27
[  468.643317] [PF_RING] Device lo does NOT support hw filtering [2]
[  468.643321] [PF_RING] Device eth1 does NOT support hw filtering [2]
[  468.643324] [PF_RING] Device eth0 does NOT support hw filtering [2]
[  468.643342] BUG: unable to handle kernel NULL pointer dereference at
0000003c
[  468.643347] IP: [<f7ec29ce>] add_device_to_ring_list+0xee/0x1c0 [pf_ring]
[  468.643356] *pde = 00000000
[  468.643359] Oops: 0000 [#1] PREEMPT SMP
[  468.643363] last sysfs file: /sys/devices/virtual/dmi/id/bios_vendor
[  468.643366] Modules linked in: pf_ring(+) binfmt_misc vboxnetadp
vboxnetflt vboxdrv nfsd lockd nfs_acl auth_rpcgss exportfs nvidia(P)
agpgart sunrpc dm_mod snd_hda_codec_realtek snd_hda_intel i2c_nforce2
i2c_core snd_hda_codec ppdev ehci_hcd ohci_hcd usbcore parport_pc
snd_hwdep rtc_cmos processor snd_pcm rtc_core nls_base rtc_lib snd_timer
psmouse pcspkr forcedeth serio_raw snd soundcore snd_page_alloc sr_mod
evdev cdrom asus_atk0110 hwmon sg via_rhine mii parport floppy button
thermal ext3 jbd mbcache ata_generic sata_nv pata_acpi pata_amd libata
sd_mod crc_t10dif scsi_mod
[  468.643411]
[  468.643415] Pid: 4726, comm: modprobe Tainted: P          
(2.6.32-un-def-alt9 #1) System Product Name
[  468.643418] EIP: 0060:[<f7ec29ce>] EFLAGS: 00210282 CPU: 1
[  468.643423] EIP is at add_device_to_ring_list+0xee/0x1c0 [pf_ring]
[  468.643425] EAX: 00000000 EBX: f14d18ec ECX: 00000000 EDX: f14d18e0
[  468.643427] ESI: f7ec5a34 EDI: f14d18f4 EBP: f30d7ef4 ESP: f30d7ea4
[  468.643430]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  468.643433] Process modprobe (pid: 4726, ti=f30d6000 task=f30ba0b0
task.ti=f30d6000)
[  468.643435] Stack:
[  468.643437]  f7ec5470 f6077000 f67c3800 f14d18e0 00000036 00000001
00000006 00200213
[  468.643443] <0> 0000000f 00000038 205b60ef 38363420 3334362e 5d303133
00200020 0000000f
[  468.643450] <0> 0000003a f67c3800 f7ec5a34 f67c3800 f30d7f10 f7ec2b1b
00008124 f14d2740
[  468.643459] Call Trace:
[  468.643465]  [<f7ec2b1b>] ? ring_notifier+0x7b/0xc0 [pf_ring]
[  468.643473]  [<c128482b>] ? register_netdevice_notifier+0x7b/0x1a0
[  468.643478]  [<f7c7c198>] ? ring_init+0x198/0x275 [pf_ring]
[  468.643483]  [<f7c7c000>] ? ring_init+0x0/0x275 [pf_ring]
[  468.643487]  [<c1001123>] ? do_one_initcall+0x23/0x180
[  468.643491]  [<c106462a>] ? blocking_notifier_call_chain+0x1a/0x20
[  468.643496]  [<c107a342>] ? sys_init_module+0xb2/0x220
[  468.643500]  [<c10f80ed>] ? sys_read+0x3d/0x70
[  468.643504]  [<c1003205>] ? syscall_call+0x7/0xb
[  468.643506] Code: 04 c6 40 08 00 b8 dc 48 ec f7 e8 ae d5 27 c9 85 c0
74 0d c7 40 38 a0 27 ec f7 8b 55 bc 89 50 34 8b 55 bc 8b 02 8b 80 b8 00
00 00 <8b> 40 3c 85 c0 0f 84 99 00 00 00 c7 45 c0 20 00 01 29 c6 45 c6
[  468.643541] EIP: [<f7ec29ce>] add_device_to_ring_list+0xee/0x1c0
[pf_ring] SS:ESP 0068:f30d7ea4
[  468.643547] CR2: 000000000000003c
[  468.643550] ---[ end trace 33eea07955838053 ]---


-- 
WBR,
Dubrovskiy Vyacheslav

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Alexey Shabalin]

2 марта 2010 г. 15:39 пользователь Slava Dubrovskiy
<slava@tangramltd.com> написал:
> 18.02.2010 15:00, Alexey Shabalin пишет:
>>
>>> 1. Собрать дополнительный модуль к ядру
>>>
>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>>
> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
> При попытке выполнить
> [root@dubrhost slava]# modprobe
> pf_ring
> Убито

А какой transparent_mode использовали?

-- 
Alexey Shabalin

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

02.03.2010 18:03, Alexey Shabalin пишет:
>>>> 1. Собрать дополнительный модуль к ядру
>>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
>> При попытке выполнить
>> [root@dubrhost slava]# modprobe pf_ring
>> Убито
>>     
> А какой transparent_mode использовали?
>   
Специально ничего не указывал, т.к. драйвера не патчены.
Должен был по умолчанию использоваться  0=standard Linux

-- 
WBR,
Dubrovskiy Vyacheslav

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Alexey Shabalin]

2 марта 2010 г. 15:39 пользователь Slava Dubrovskiy написал:
> 18.02.2010 15:00, Alexey Shabalin пишет:
>>
>>> 1. Собрать дополнительный модуль к ядру
>>>
>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>>
> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
> При попытке выполнить
> [root@dubrhost slava]# modprobe
> pf_ring
> Убито

У меня загрузился без проблем:
#modinfo pf_ring
filename:       /lib/modules/2.6.32-std-def-alt9/pf_ring/pf_ring.ko
alias:          net-pf-27
description:    Packet capture acceleration by means of a ring buffer
author:         Luca Deri <deri@ntop.org>
license:        GPL
srcversion:     1588EE2C94A339482ABBA16
depends:
vermagic:       2.6.32-std-def-alt9 SMP mod_unload modversions 586
parm:           num_slots:Number of ring slots (uint)
parm:           transparent_mode:0=standard Linux,
1=direct2pfring+transparent, 2=direct2pfring+non transparentFor 1 and
2 you need to use a PF_RING aware driver (uint)
parm:           enable_tx_capture:Set to 1 to capture outgoing packets (uint)
parm:           enable_ip_defrag:Set to 1 to enable IP
defragmentation(only rx traffic is defragmentead) (uint)

# modprobe pf_ring

# dmesg
[  510.098750] [PF_RING] Welcome to PF_RING 4.1.3 ($Revision: $)
[  510.098753] (C) 2004-10 L.Deri <deri@ntop.org>
[  510.098771] [PF_RING] registered /proc/net/pf_ring/
[  510.098775] NET: Registered protocol family 27
[  510.098784] [PF_RING] Device lo does NOT support hw filtering [2]
[  510.098789] [PF_RING] Device e100 does NOT support hw filtering [2]
[  510.098795] [PF_RING] Device integ does NOT support hw filtering [2]
[  510.098800] [PF_RING] Device pan0 does NOT support hw filtering [2]
[  510.098805] [PF_RING] Device virbr1 does NOT support hw filtering [2]
[  510.098809] [PF_RING] Ring slots       4096
[  510.098812] [PF_RING] Slot version     10
[  510.098814] [PF_RING] Capture TX       Yes [RX+TX]
[  510.098817] [PF_RING] Transparent Mode 0
[  510.098819] [PF_RING] IP Defragment    No
[  510.098821] [PF_RING] Initialized correctly

-- 
Alexey Shabalin

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

03.03.2010 15:01, Alexey Shabalin пишет:
>>>> 1. Собрать дополнительный модуль к ядру
>>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
>> При попытке выполнить
>> [root@dubrhost slava]# modprobe
>> pf_ring
>> Убито
>>     
> У меня загрузился без проблем:
> #modinfo pf_ring
> filename:       /lib/modules/2.6.32-std-def-alt9/pf_ring/pf_ring.ko
> alias:          net-pf-27
> description:    Packet capture acceleration by means of a ring buffer
> author:         Luca Deri <deri@ntop.org>
> license:        GPL
> srcversion:     1588EE2C94A339482ABBA16
> depends:
> vermagic:       2.6.32-std-def-alt9 SMP mod_unload modversions 586
> parm:           num_slots:Number of ring slots (uint)
> parm:           transparent_mode:0=standard Linux,
> 1=direct2pfring+transparent, 2=direct2pfring+non transparentFor 1 and
> 2 you need to use a PF_RING aware driver (uint)
> parm:           enable_tx_capture:Set to 1 to capture outgoing packets (uint)
> parm:           enable_ip_defrag:Set to 1 to enable IP
> defragmentation(only rx traffic is defragmentead) (uint)
>
> # modprobe pf_ring
>   
А покажите плиз rpm -qa | grep kernel | sort

-- 
WBR,
Dubrovskiy Vyacheslav

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Alexey Shabalin]

3 марта 2010 г. 16:46 пользователь Slava Dubrovskiy
<slava@tangramltd.com> написал:
> 03.03.2010 15:01, Alexey Shabalin пишет:
>>>>> 1. Собрать дополнительный модуль к ядру
>>>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>>> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
>>> При попытке выполнить
>>> [root@dubrhost slava]# modprobe
>>> pf_ring
>>> Убито
>>>
>> У меня загрузился без проблем:
>> #modinfo pf_ring
>> filename:       /lib/modules/2.6.32-std-def-alt9/pf_ring/pf_ring.ko
>> alias:          net-pf-27
>> description:    Packet capture acceleration by means of a ring buffer
>> author:         Luca Deri <deri@ntop.org>
>> license:        GPL
>> srcversion:     1588EE2C94A339482ABBA16
>> depends:
>> vermagic:       2.6.32-std-def-alt9 SMP mod_unload modversions 586
>> parm:           num_slots:Number of ring slots (uint)
>> parm:           transparent_mode:0=standard Linux,
>> 1=direct2pfring+transparent, 2=direct2pfring+non transparentFor 1 and
>> 2 you need to use a PF_RING aware driver (uint)
>> parm:           enable_tx_capture:Set to 1 to capture outgoing packets (uint)
>> parm:           enable_ip_defrag:Set to 1 to enable IP
>> defragmentation(only rx traffic is defragmentead) (uint)
>>
>> # modprobe pf_ring
>>
> А покажите плиз rpm -qa | grep kernel | sort
тебя интересует версия ядра? выше указано, что 2.6.32-std-def-alt9
(пока пробую на 32bit)

-- 
Alexey Shabalin

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

04.03.2010 09:40, Alexey Shabalin пишет:
>>>>>> 1. Собрать дополнительный модуль к ядру
>>>>>>             
>>>>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>>>>>           
>>>> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
>>>> При попытке выполнить
>>>> [root@dubrhost slava]# modprobe
>>>> pf_ring
>>>> Убито
>>>>         
>>> У меня загрузился без проблем:
>>> #modinfo pf_ring
>>> filename:       /lib/modules/2.6.32-std-def-alt9/pf_ring/pf_ring.ko
>>> alias:          net-pf-27
>>> description:    Packet capture acceleration by means of a ring buffer
>>> author:         Luca Deri <deri@ntop.org>
>>> license:        GPL
>>> srcversion:     1588EE2C94A339482ABBA16
>>> depends:
>>> vermagic:       2.6.32-std-def-alt9 SMP mod_unload modversions 586
>>> parm:           num_slots:Number of ring slots (uint)
>>> parm:           transparent_mode:0=standard Linux,
>>> 1=direct2pfring+transparent, 2=direct2pfring+non transparentFor 1 and
>>> 2 you need to use a PF_RING aware driver (uint)
>>> parm:           enable_tx_capture:Set to 1 to capture outgoing packets (uint)
>>> parm:           enable_ip_defrag:Set to 1 to enable IP
>>> defragmentation(only rx traffic is defragmentead) (uint)
>>>
>>> # modprobe pf_ring
>> А покажите плиз rpm -qa | grep kernel | sort
>>     
> тебя интересует версия ядра? выше указано, что 2.6.32-std-def-alt9
> (пока пробую на 32bit)
>   
Интересует какие еще дополнительные модули стоят

-- 
WBR,
Dubrovskiy Vyacheslav

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

04.03.2010 14:45, Slava Dubrovskiy пишет:
> 04.03.2010 09:40, Alexey Shabalin пишет:
>   
>>>>>>> 1. Собрать дополнительный модуль к ядру
>>>>>>>             
>>>>>>>               
>>>>>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>>>>>>           
>>>>>>             
>>>>> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
>>>>> При попытке выполнить
>>>>> [root@dubrhost slava]# modprobe
>>>>> pf_ring
>>>>> Убито
>>>>>         
>>>>>           
>>>> У меня загрузился без проблем:
>>>> #modinfo pf_ring
>>>> filename:       /lib/modules/2.6.32-std-def-alt9/pf_ring/pf_ring.ko
>>>> alias:          net-pf-27
>>>> description:    Packet capture acceleration by means of a ring buffer
>>>> author:         Luca Deri <deri@ntop.org>
>>>> license:        GPL
>>>> srcversion:     1588EE2C94A339482ABBA16
>>>> depends:
>>>> vermagic:       2.6.32-std-def-alt9 SMP mod_unload modversions 586
>>>> parm:           num_slots:Number of ring slots (uint)
>>>> parm:           transparent_mode:0=standard Linux,
>>>> 1=direct2pfring+transparent, 2=direct2pfring+non transparentFor 1 and
>>>> 2 you need to use a PF_RING aware driver (uint)
>>>> parm:           enable_tx_capture:Set to 1 to capture outgoing packets (uint)
>>>> parm:           enable_ip_defrag:Set to 1 to enable IP
>>>> defragmentation(only rx traffic is defragmentead) (uint)
>>>>
>>>> # modprobe pf_ring
>>>>         
>>> А покажите плиз rpm -qa | grep kernel | sort
>>>     
>>>       
>> тебя интересует версия ядра? выше указано, что 2.6.32-std-def-alt9
>> (пока пробую на 32bit)
>>   
>>     
> Интересует какие еще дополнительные модули стоят
>   
Обновился до 2.6.32-std-def-alt9 и заработало. Только сегодня доехало
это ядро.

-- 
WBR,
Dubrovskiy Vyacheslav

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Slava Dubrovskiy]

04.03.2010 14:45, Slava Dubrovskiy пишет:
> 04.03.2010 09:40, Alexey Shabalin пишет:
>   
>>>>>>> 1. Собрать дополнительный модуль к ядру
>>>>>>>             
>>>>>>>               
>>>>>> Первый пункт я сделал :) модуль ядра отправил в сизиф.
>>>>>>           
>>>>>>             
>>>>> Не работает у меня. Пробовал на 2 разных железках с ядрами std-def и un-def
>>>>> При попытке выполнить
>>>>> [root@dubrhost slava]# modprobe
>>>>> pf_ring
>>>>> Убито
>>>>>         
>>>>>           
>>>> У меня загрузился без проблем:
>>>> #modinfo pf_ring
>>>> filename:       /lib/modules/2.6.32-std-def-alt9/pf_ring/pf_ring.ko
>>>> alias:          net-pf-27
>>>> description:    Packet capture acceleration by means of a ring buffer
>>>> author:         Luca Deri <deri@ntop.org>
>>>> license:        GPL
>>>> srcversion:     1588EE2C94A339482ABBA16
>>>> depends:
>>>> vermagic:       2.6.32-std-def-alt9 SMP mod_unload modversions 586
>>>> parm:           num_slots:Number of ring slots (uint)
>>>> parm:           transparent_mode:0=standard Linux,
>>>> 1=direct2pfring+transparent, 2=direct2pfring+non transparentFor 1 and
>>>> 2 you need to use a PF_RING aware driver (uint)
>>>> parm:           enable_tx_capture:Set to 1 to capture outgoing packets (uint)
>>>> parm:           enable_ip_defrag:Set to 1 to enable IP
>>>> defragmentation(only rx traffic is defragmentead) (uint)
>>>>
>>>> # modprobe pf_ring
>>>>         
>>> А покажите плиз rpm -qa | grep kernel | sort
>>>     
>>>       
>> тебя интересует версия ядра? выше указано, что 2.6.32-std-def-alt9
>> (пока пробую на 32bit)
>>   
>>     
> Интересует какие еще дополнительные модули стоят
>   
Нашел виновника.
Удалил kernel-modules-virtualbox-std-def и заработало. А когда загружены
модули для виртуалбокса - не работает. Наверно нужно конфликт ставить.

-- 
WBR,
Dubrovskiy Vyacheslav

Re: [devel] Потеря пакетов libpcap и как с этим бороться

[Alexey Shabalin]

>>>>>>>> 1. Собрать дополнительный модуль к ядру
>>>>>>> Первый пункт я сделал :) модуль ядра отправил в сизиф.

некоторые пересобранные пакеты можно взять на ftp.a.o/people/shaba/pf_ring

Обновлены версии пакетов: libpcap,tcpdump,nmap,ntop,snort (всё есть в git)
Просто пересобраны: p0f, trafshow

to ldv: обноружил, что tcpdump на x86_64 собирается без поддержки
libcrypt. В git поправил. Багу вешать не стал, вдруг NMU разрешишь.


Успешно проверена работа(запушены и работают, проверял естесственно не
во всевозможных режимах) trafshow, nmap, ntop, snort.
Ядерный модуль подгружается автоматически.

Выдержка из лога:
Mar  4 16:30:00 netstat ntop[3454]:   Initializing ntop
Mar  4 16:30:00 netstat kernel: [   16.396435] [PF_RING] Welcome to
PF_RING 4.1.3 ($Revision: $)
Mar  4 16:30:00 netstat kernel: [   16.396436] (C) 2004-10 L.Deri
<deri@ntop.org>
Mar  4 16:30:00 netstat kernel: [   16.396449] [PF_RING] registered
/proc/net/pf_ring/
Mar  4 16:30:00 netstat kernel: [   16.396451] NET: Registered
protocol family 27
Mar  4 16:30:00 netstat kernel: [   16.396456] [PF_RING] Device lo
does NOT support hw filtering [2]
Mar  4 16:30:00 netstat kernel: [   16.492989] [PF_RING] Device sniff
supports hw filtering
Mar  4 16:30:00 netstat kernel: [   16.593070] [PF_RING] Device int
supports hw filtering
Mar  4 16:30:00 netstat kernel: [   16.593489] [PF_RING] Ring slots       4096
Mar  4 16:30:00 netstat kernel: [   16.593491] [PF_RING] Slot version     10
Mar  4 16:30:00 netstat kernel: [   16.593492] [PF_RING] Capture TX
   Yes [RX+TX]
Mar  4 16:30:00 netstat kernel: [   16.593493] [PF_RING] Transparent Mode 0
Mar  4 16:30:00 netstat kernel: [   16.593494] [PF_RING] IP Defragment    No
Mar  4 16:30:00 netstat kernel: [   16.593495] [PF_RING] Initialized correctly
Mar  4 16:30:00 netstat kernel: [   16.594572] [PF_RING] successfully
allocated 2043904 bytes at 0xffffc900047fe000
Mar  4 16:30:00 netstat kernel: [   16.594575] [PF_RING] allocated
4103 slots [slot_len=498][tot_mem=2043904]
Mar  4 16:30:00 netstat kernel: [   16.595667] [PF_RING] successfully
allocated 2043904 bytes at 0xffffc900049f3000
Mar  4 16:30:00 netstat kernel: [   16.595670] [PF_RING] allocated
4103 slots [slot_len=498][tot_mem=2043904]
Mar  4 16:30:00 netstat kernel: [   16.611726] NET: Registered
protocol family 17
Mar  4 16:30:00 netstat kernel: [   16.611848] device sniff entered
promiscuous mode
Mar  4 16:30:00 netstat ntop[3454]:   Checking sniff for additional devices

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

-- 
Alexey Shabalin