Уважаемые товарищи программисты!!!!
Если кто работал с WinPcap - такая проблема, когда я включаю на перехват пакетов свою прогу с помощью функции:



У меня подвисает окно полностью, кто знает как помоч, пожалуйста, как можно скорее ответте - что делать?

WebDragon

pcap_loop тут непричем, твое окно повиснет даже если ты напишеш


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

Решения
1. запускать loop в отдельном потоке
2. найти аналог функции который не запускает цикла и организовать цикл вручную

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

вот мануал
http://www.manpagez.com/man/3/pcap_loop/



так должно сработать


На билдере не могу, у меня нет билдера. На память не напишу, давно это было.
можно через _beginthreadex


код покажи - поправим

Это сообщение отредактировал(а) azesmcar - 26.4.2009, 00:26

Спапсибо, нашел как еще поток создать, все работает

Это сообщение отредактировал(а) WebDragon - 9.5.2009, 23:16

кто-нибудь использовал WinPcap для перехватывания пакетов на удаленной машине? у меня возникла проблема с этим. задача следующая: 
1. получаем список сетевых устройств с локальной машины и с удаленной.
2. выбираем по одному и там и там.
3. открываем их с параметром promisculousmode = false.
4. устанавливаем на оба устройства одинаковый фильтр вида: (src host <local host> and dst host <remote host> and dst port <port on remote host>) or (src host <remote host> and src port <port on remote host> and dst host <local host>).
5. в качестве обработчиков события прихода пакетов выставляем простые процедуры, в которых реализован подсчет кол-ва вызовов. для локального и удаленного устройства отдельно.
6. засекаем время и начинаем отслеживание и там и там
7. выполняем запрос на <remote host> (я выполнял обычный SQL-запрос к MSSQL Server, который работает с 1433 портом)
8. выключаем отслеживание и получаем временной интервал - затраченное время.
цель в том, чтобы разделить потраченное время на три части: 1) время прохождения пакетов от локальной машины до удаленной (запрос), 2) время обработки запроса на сервере, 3) время прохождения пакетов от удаленной машины до локальной (ответ).

и вот проблемы: 
1. счетчики показывают сильно разнящиеся числа. скажем, входящих/исходящих пакетов на локальном устройстве в 3-4 раза меньше, чем на удаленном, что при таком фильтре вызывает недоумение.
2. в результате экспериментов выяснилось, что события отправления с одного устройства и прихода пакета на другое устройство генерируются в странном порядке - у меня несколько раз получалось так, что пакет как бы сначала приходил на точку назначения, а уже после отправлялся. хотя пометки времени в заголовке пакетов проставляются драйвером перехвата корректно.

кто-нибудь сталкивался с подобным?

TCP/IP стек порезал пакеты, имеет право   Пардон, стек не при чем - на голые пакеты он не влияет. Пакеты могли потеряться по дороге из за колизий (и роутинга, если он был) Статистику не пробовали смотреть?

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



Это сообщение отредактировал(а) xvr - 19.6.2009, 14:44

Разве локальное время этих машин влияет на очередность генерации событий? А тут иногда (но не всегда!) получается так, что событие получения пакета генерируется раньше чем событие отправки пакета. Возможно ли, что потеря пакетов и эта неразбериха с генерацией событий происходит из-за переполнения буфера сохранения пакетов? 
И еще вопрос, который меня мучает уже неделю: возможно ли как-то сравнить два произвольных пакета, которые переданы параметром в процедуру обработки прихода пакета? Уточняю: "Пакет ушел с машины А и пришел на машину В. Это тот самый пакет, который ушел с машины А?"

Это сообщение отредактировал(а) Avashah - 22.6.2009, 10:43

На очередность - нет. А на время, которое стоит в timestamp пакета - да. Эти времена суть локальные времена машин, где пакет принят/передан, и могут отличаться.
События генерируются на разных машинах и доставляются на одну. Порядок их генерации вполне фиксированн, а вот порядок приема - нет, так как процесс доставки события сам по себе занимает время, причем недетерминированное

Может.
Если хотите ТОЧНО восстановить очередность, надо полагаться не на порядок приема пакетов, а на timestamp в winpcap описателях пакетов. Но нужно засинхронизовать время на компах (см NTP)

Сравнить содержимое (или лучше какой нибудь хэш, типа MD5 или SHA1)

Да, это ясно.

Вот оно что... Ясно.

Сейчас я сравниваю МАС-адреса пакетов (источника и назначения), а так же побайтово блок данных пакетов. Однако возникло бредовое подозрение, что после получения пакета пакет может быть отличен от оригинала. Основано оно на том, что я просто выводил в отдельные файлы исходящие и приходящие пакеты на обоих устройствах, а потом просто пытался провести параллель между тектовыми представлениями серий пакетов. Разубедите меня пожалуйста!
p.s. Большое спасибо за информацию! Я как-будто решал систему из одного уравнения, но с несколькими неизвестными. Теперь все более понятно.
p.p.s. Кстати, пакеты отлавливаются Pcap-драйвером до фрагментирования или после? 

Это сообщение отредактировал(а) Avashah - 22.6.2009, 17:25

Не должно. Ethernet MAC пакеты при передаче/приеме не модифицирует.

Мне вот тут подсказывают, что измениться может как минимум заголовок, но это я предполагал. Как же быть? Что неизменное в пакете? Ведь блок данных может повторяться в разных пакетах, и по нему так же однозначно идентифицировать пакет нельзя.

Заголовок не будет меняться если у вас прямое соединение (хаб либо свич). Если по дороге стоит маршрутизатор, то пакет вполне могут вообще порубить в капусту   

Стоп, стоп Давайте разберемся: если у нас два открытых устройства - локальное и удаленное, то во время отправки пакетов с локальной на удаленную собылие отправки всяко должно происходить раньше, оно же никуда не доставляется. А тут почему-то не всегда так. Есть какие-то тонкости?

Маршрутизатор рассматривать не будем, т.к. в таком случае толком фильтр не построишь

Доставляется - из драйвера в приложение. Удаленное событие (приемки) тоже доставляется - от TCP/IP стека (через которое оно идет) опять же до приложения.