- Помогите с libipq,
 Olej, 15:20 , 26-Май-03 (1)>Значит решил я зантся перехватом пакетов с помощью ip_queue.
>Скачал последний iptables 1.2.8 поставил.
>Подключил include <libipq.h>
>И скопировал прогу из man libipq.
>Результате Kdevelop сообщает - на все функции libipq - unknoun referens for
>this funktion.
>
>Я конечно новичок в программировании под Линукс, но вот прям сразу такая
>ошибка :(Какая "такая"? Скорее всего, gcc нужно ручками указать (ключ "-l"-эл) использовать библиотеку libipq... Попутный вопроса: а чего все (несколько раз уже видел на разных форумах) "вцепились" в эту libipq? Что в ней такого есть, чего нет, например, в libpcap и BPF (Bercley Packet Filter) - у этого tools-а, по крайней мере, есть уже приличная история улучшений и усовершенствований, да и по оценкам производительности ОНО намного выше пакетного сокета Linux и др. ... Так всё же?
- Помогите с libipq, havester, 17:51 , 26-Май-03 (2)
- Помогите с libipq, Olej, 18:21 , 26-Май-03 (3)
>Извини за глупость но что за параметр -l? Расскажи поподробнее? library, напр.:
gcc ... -lsocket -Bstatic ...
- собирать, статически прилинковавши libsocket.so
- Помогите с libipq, havester, 09:24 , 27-Май-03 (4)
- Помогите с libipq, J, 12:29 , 27-Май-03 (5)
- Помогите с libipq, havester, 15:54 , 27-Май-03 (6)
- Помогите с libipq, J, 16:45 , 27-Май-03 (7)
- Помогите с libipq, havester, 17:09 , 27-Май-03 (8)
- Помогите с libipq, Olej, 13:07 , 28-Май-03 (12)
>Остался один вопрос. Мне бы url из http и ftp? URL - не дам: самому искать надо, но вот ключевое слово ("заветное" ;-)) - пожалуйста: "RFC" - любой поисковик его знает... Это не в шутку, а всерьёз: единственный документ, заслуживающий доверия по любому из сетевых протоколов или механизмов - RFC (ну не Windows же HELP :D?). Читайте RFC! Там их, на сегодня, что-то около 3000 документов :-(, но есть средства отобрать по тематикам ... десятка полтора там будут и по HTTP/FTP.
- Помогите с libipq, Olej, 13:02 , 28-Май-03 (11)
>TCP, UDP, ICMP - разновидность IP-пакетов, внутри IP пакета находятся данные верхнего
>уровня модели OSI, внутри TCP-пакетов передаются данные ftp-сессий, например, и тд. TCP, UDP, ICMP, IGMP etc. - это не "разновидности" - а автономные протоколы (например - они без изменения работают с IPv6) более высокого уровня транспортного протокола IP (у MS таким же образом над IP надстроено "одоробло" NETBEUI...). А TCP/IP - модели OSI не соответствует, раньше он создавался... и даже все искусственные попытки "натянуть" его на модель так и остались ... неадекватными ;-). >Надо рассматривать все последовательно, разворачивая загоолвок за заголовком. Но на анализ
>контента, имхо, никаких ресурсов не хватит. Нет, ну точно: сейчас перепишут IP-стек... А что вы с пакетами MAC-уровня станете делать: ARP, RARP ... etc. - а их любой снифер (нормальный, см. BPF - libcap - tcpdump) также отлично перехватывает. Пацаны ... прекращайте чудить...
"Спили мушку..." - как было сказано в одном умном месте...
- Помогите с libipq, J, 12:14 , 29-Май-03 (18)
- Помогите с libipq, Olej, 13:33 , 02-Июн-03 (20)
>Я хотела сказать, что и TCP и UDP и ICMP и IGMP
>и GRE и XTP и IPinIP - это все IP
>пакеты на более низком уровне, в отличие от ARP.
Если уж совсем точно, то не "низком", а "более высоком" (вплоть до прикладного, напр. HTTP)... но это уже дело вкуса ;-)>>А TCP/IP - модели OSI не соответствует, раньше он создавался... и даже
>>все искусственные попытки "натянуть" его на модель так и остались ...
>>неадекватными ;-).
>
>Соответствует, только не надо все принимать букваьлно. По крайней мере, он соответствует
>идеологии OSI, ее матрешечному принципу наслоения заголовков и работе с заголовками
>более высших уровней как с данными.
А вот тут - позвольте с вами серьёзно не согласиться: НЕ СООТВЕСТВУЕТ (ну ... максимум - "чем-то похож") - об этом много писалось, и глухое "притягивание" модели OSI к IP часто приводит к серьёзным искажениям представлений о последнем... >>Нет, ну точно: сейчас перепишут IP-стек...
>
>А вы пробовали? :-)
>Ну, хотя бы не глобально, а добавить поддержку нового вида протокола на
>основании имеющегося в линуксовом стеке протокола родственного типа?
1.Конечно пробовал, я этими штучками ... обмен данных, сетевые протоколы etc. занимаюсь года с 1980 - всего насмотрелся и напробовался...
2. ... а потом года с 1984-го, потому как некому было этим тогда заниматься, читал спецкурс об этом subj аспирантам - "товарищам учёным", которые сейчас и пишут об subj статьи и книжки.
3."Не плодите понятий больше, чем сущностей..." (с) кажется А.Пуанкаре - если нужно только перехватывать пакеты (в самых разных модификациях), и для этого есть море tools - не нужно делать "свои протоколы" etc., лучше направить эту энергетику в более созидательное русло. >>А что вы с пакетами MAC-уровня станете делать: ARP, RARP ... etc.
>>- а их любой снифер (нормальный, см. BPF - libcap -
>>tcpdump) также отлично перехватывает.
>
>Мне оно как бы ни к чему. Полезно только для диагностики хитрого
>девайса, который вечто забывает свой мак-адрес (но при это продолжает работать).
Разговор был о "снифере" - полноценный снифер должен уметь делать перехват на ВСЕХ уровнях.
- Помогите с libipq, Olej, 12:53 , 28-Май-03 (10)
>берете заголовок ip-пакета (или что там вытаскивает libipq) и разбираете его поля
>
>описание заголовка точно есть в каком-то из .h файлов в стандартном наборе
>инклюдов "Ну вы блин даёте..." (с)
Вы так что - хотите весь IP-стек по-новой переписать, когда вам всего-навсего нужно снифер пакетов?
- Помогите с libipq, havester, 14:23 , 28-Май-03 (13)
- Помогите с libipq, Olej, 16:37 , 28-Май-03 (14)
>В том то и дело что не хочу, поэтому и спраштваю.
>Про libpcap я уже писал, почему неподходит. Хотя, наверно, там есть функции
>которые бы мне помогли? Это "неподходит" ... неподходит - неубедительно: там где-то, какой-то Вася Пупкин говорит.... У меня на заборе такое понаписано! - если бы я всему верил... BPF, и все его производные: libcap, tcpdump - это profesional tools, которые отрабатываются - улучшаются уже лет 8, и настоящими профиссионалами ... поэтому то, что говорят "юные писаки" доморощенных якобы-сниферов для меня - не аргумент... Аргументы - где!?
- Помогите с libipq, Olej, 12:45 , 28-Май-03 (9)
>Как из них выдернуть пакет в удобочитаемой форме.
>Хотнлось бы конечо чтобы сразу разбивал на
>TCP->http
> ->ftp
> ->pop3
> ->и т.д.
>UDP
>ICMP
>и т.д.
>
>Есть ли такие библы? Есто: BPF + libcap :D :D :D
- Помогите с libipq, havester, 17:00 , 28-Май-03 (15)
- Помогите с libipq, Olej, 18:17 , 28-Май-03 (16)
>Хорошо. Вот такая ситуация. В машине 3 100 мб сетевухи, демон ВПН.
>
>Все это разруливается. А машина скажем целерон 600.
>Ты моежешь со 100% уверенностью сказать, что ни один из пакетов не
>уйдет от логирования в базу? 100% гарантии даёт только одна инстанция - морг!
Это не я сказал, т.е. (с) - только источника не помню. Я слабо понимаю то, что сказано выше - что такое "разруливается", я понимаю, когда говорят: ICMP, IGMP, NAT-трансляция ... и т.п. - т.е. есть однозначная техническая терминология - давайте ею пользоваться. Почему не должно быть гарантии в каком-то (многократно, множеством людей выверенном) пакете, например BPF - и она вдруг должна появиться в какой-то самопалке? И число мгц. здесь не при чём - на какой частоте стек IP принимает/отсылает пакеты - на той же частоте BPF их перехватывает... поставим 4Ghz - всё то-же останется, только масштаб изменится. А пропуск (пропадание) пакетов в любом tools-е никак не является функцией технических характеристик (Mhz, Mb, Mbod etc.) - а только зависит от степени кривизны рук, которыми эту tools-у делали... А вообще: "вообще нет программ не содержащих ошибки - отличается только частота, с которой они проявляются при использовании..." (с) Э.Дейкстра - классика.
- Помогите с libipq, havester, 09:24 , 29-Май-03 (17)
- Помогите с libipq, Olej, 13:45 , 02-Июн-03 (21)
>>Почему не должно быть гарантии в каком-то (многократно, множеством людей выверенном) пакете,
>>например BPF - и она вдруг должна появиться в какой-то самопалке?
>>И число мгц. здесь не при чём - на какой частоте
>>стек IP принимает/отсылает пакеты - на той же частоте BPF их
>>перехватывает... поставим 4Ghz - всё то-же останется, только масштаб изменится.
>Еще раз повторяю. Может случится что повиснет libpcap? Может. Тогда весь трафик
>пройдет мимо админа.
Может и так случиться ;-).
Только...:
- если это у вас под ВЫНЬ (чего-то мне так показалось) - то эта самая ВЫНЬ (какая бы она не была "устойчивая" - NT, 2000, XP) - "упадёт" до этого события уже 1000 раз, так что в падении Libcap ничего такого страшного (непривычного :D) и не будет...
- упасть может любая прога, но ... см. выше того же Э.Дейкстру, он там ещё что-то про "ручки" говорил - любой "быстренький самопальный" снифер упадёт со 100 раз большей вроятностью, учитывая проработанность и отработанность BPF + libcap.>Да не является пока машина справляется.
>А если у нее и без перехвата при 60% загрузки сети -
>занято 80% ресурсов.
>Что будет если поднимится загрузка на 3 картах до хотя бы 80%.
>Я так думаю что ядро посылать то пакеты будет, а вот
>отсанется ли процессорного времени на снифер...
А я думаю как-раз наоборот: BPF в UNIX работает в режиме ядра ... и, если уж кому не станет хватать процессорного времени, так это пользовательскому приложению на "отправлять-принимать". Но, как я помню по опыту работы с BPF + tcpdump - они добавляли столь мало существенную нагрузку к общей загрузке, что это мало что значило. >Но прошу так же предоставить ваши достоверные данные, а не утверждения что
>работало 10 лет, за 10 лет многое поменялось.
1. "мои достоверные данные" - это то, что достаточно периодическое использование BPF не даёт повода сомневаться... А доказывать (или ссылаться на утверждения) нужно "глюкавость", а не её отсутствие - презумпция невиновности. Ещё более достоверные гарантии ... так это только у инстанции ... см. выше ... ;-)
2. не "работало 10 лет" - а постоянно развивается и вылизывается на протяжении почти 10-ти лет... Как говорят в Одессе: "жениться и обещать жениться - это две большие разные вещи".
- Помогите с libipq, havester, 09:17 , 30-Май-03 (19)
- Помогите с libipq, Alexander_B, 12:42 , 07-Июл-03 (24)
|
Версия для распечатки
Помогите с libipq, 
