Уважаемые товарищи программисты!!!!
Если кто работал с 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 стека (через которое оно идет) опять же до приложения.

Известны ли Вам реализации NTP протокола на .NET языках с открытым кодом? Существут SNTP клиент на C#, однако упрощенный протокол не позволяет получить разницу во времени между двумя машинами с точностью выше чем 1 секунда.
Подозреваю, что в локальной сети можно поднять NTP-сервер и синхронизировать с ним целевые машины. Однако, это не всегда осуществимо.
p.s. Простите, что не в тему

Это сообщение отредактировал(а) Avashah - 23.6.2009, 15:29

Мне неизвестны, однако это не значит, что их нету   
Но точно есть на С
Вполне осуществимо, сервер можно запустить самому. А вот конектится к удаленным NTP серверам явно не всегда осуществимо, может банально не быть доступа в Inet

Не осуществимо в том смысле, что клиент не допустит установку NTP сервера. А на счет интернета - я так понял, что для синхронизации времени в локальной сети с одной из машин внутри той же сети, интерент и не нужен.
 
Если есть ссылка, то было бы просто супир!

Но запуск программы он допустит? NTP сервер вполне можно сделать программой. Можно его сделать и не сервером - ведь нужно всего лишь получить точную разницу часов на 2х машинах. NTP протокол (и сорцы сервера и клиента) вполне подойдут
Нужен сервер. C# клиент, на который была ссылка, использовал сервера из Интернета

 http://www.ntp.org/

По поводу структуры отловленного пакета: вот здесь сказано, что "Для выделения границ блоков принятых данных BPF снабжает их заголовком, содержащим время приема и размер блока, а также концевиком для синхронизации блоков данных." То же самое справедливо и для NDIS? Играет ли это какю-либо роль при сравнении уходящего/приходящего пакета? Я имею ввиду, что WinPcap при генерации события отправки/получения пакета передает в pcap_handler заголовок, добавляемый драйвером захвата, и сам пакет (целиком или фрагмент?). Так входит ли во второй параметр тот самый "концевик"? Это конечно напрямую зависит от того, передается ли в callback процедуру пакет целиком или фрагментарно. 
Как Вы думаете, разумно ли сравнивать пакеты по их CRC-сумме? 

Он может получать время с любой доступной машины, как в локальной сети, так и в Internet, лишь бы был открыт 123-й порт. В этом исходниках этого клиента есть несколько проблем, но они решаемы. Проблема в том, что он не дает желаемой точности 

Да, именно так. Однако, откровенно говоря, С/С++ мне практически незнакомы. Начинал с Delphi, теперь перешел на C#. А под .Net найти открытой реализации NTP клиента пока не удалось.

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

Пакет целиком, с Ethernet заголовком, но без CRC поля.
Пакет целиком
Если только вы ее сами посчитаете

Вам не нужна 'любая' машина, вам нужно засинхронизовать 2 свои машины. Конечно можно засинхронизовать обе машины с 3й в сети, но тогда на машинах нужны клиенты, встроенные в систему, что бы они синхронизировали именно системное время. Кроме того, 123 порт должен не просто 'быть открытым', на нем должен работать NTP сервер
Сам NTP дает гораздо большую точность, чем 1секунда.
Как только MS ядро ОС на .net напишет, так сразу   

Ну вот смотрите: вышеуказанный клиент, реализующий SNTP протокол, может получить разницу во времени с любой машины, по крайней мере в локальной сети, если она доступна. Т.е. видимо для этого достаточно стандартных средств Windows (возможно, 123 порт слушает служба синхронизации веремни). Никакого сервера там устанавливать не нужно для этого. С клиентом, реализующим NTP протокол, я полагаю, дело обстоит сложнее. Без установки сервера NTP на той машине, с которой будем синхронизироваться, не обойдешься. Но это так, к слову. Я уже понял, что написание NTP клиента под .net весьма проблематично, как и поиск исходников. Остается, либо брать готовое ядро на C/C++ и использовать его, либо пользоваться готовым софтом для синхронизации времени. Один вариант я уже нашел, но он как минимум не очень удобен. В любом случае, спасибо за консультацию!

Да действительно. Сервер там уже есть (живет в w32time.dll в system32)
Уже стоит
Проще. Нам не надо синхронизировать системные часы, поэтому клиент не обязан быть частью системы - мы можем его включить в состав своей программы
Он уже есть

Угу

На сайте разработчиков отдельно не выкладываются ни исходники ядра, ни само ядро NTP клиента (в виде библиотеки, например). Исходя из моих скромных знаний С, могу предположить, что посылку запроса и получение ответа (функции sendrequest и getresponce соответственно) достаточно затруднительно отделить от реализации ntpd. Поправьте меня, если я ошибаюсь.
Кстати, ntpdate не может получить разницу во времени, если на предполагаемом сервере времени не запущен ntpd. Получается, стандартных средств (w32time.dll) недостаточно для ответа? 

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

На сайте разработчиков выложены ИСКЛЮЧИТЕЛЬНО исходники этого всего
 http://www.eecis.udel.edu/~ntp/ntp_spool/n...tp-4.1.2.tar.gz

Соответствующие RFC читать не пробовали? На сайте есть ссылки

Я не знаю, какую часть функциональности реализует w32time.dll, надо смотреть MSDN

А вот такая деталь: в протоколе TCP фигурирует механизм квитирования - "отчет о доставке" каждого кадра, входящего в TCP пакет.  В WinPcap же событие прихода пакета, как я понял, генерируется для всего пакета (собранного из кадров), а не для каждого кадра в отдельности. Соответственно, на каждое событие отправления TCP пакета будет приходиться несколько событий получения "отчета о доставке", ведь каждая квитанция идет отдельным пакетом.  Верно?
p.s. хотя вероятно неверно. При использовании протокола TCP поток байт, подлежащих передаче, делится на сегменты. Каждый сегмент передается отдельным TCP пакетом (которые и будут "отловлены" WinPcap) со своим номером последовательности (где номер последовательности - это число уже переданных байтов из исходной последовательности + 1), а так же набором флагов SYN и ACK. При получении пакета получатель (Б) информирует отправителя (А) о получении. Это происходит посредством отправки ответного TCP пакета (возможно после обработки исходного, а так же ответ получателя Б сам может являться новым запросом каких-то данных у точки А), где указывается номер подтверждения, равный общему числу полученных байт данных от точки А... Каша в голове. Так что же выступает подтверждением доставки? Если в ответ на пакет из А в Б с номером последовательности N, получаем пакет из Б в А с номером подтверждения > N. Так? Причем, совершенно необязательно, что подтверждение придет сразу же. Так?
При помощи WinPcap мы сможем отследить и запрос и подтверждение. Но сможем ли мы по этим двум пакетам определить (хотя бы приблизительно) время, затраченное на доставку? Ведь на два запроса может придти одно подтверждение.

Это сообщение отредактировал(а) Avashah - 7.7.2009, 12:54

Угу
Для Ethernet пакета, а не TCP пакета. WinPcap работает на более низком уровне, чем даже голый IP (не говоря уже об TCP)
Нет. Квитанция будет 1 штука (максимум) на весь TCP пакет, или даже меньше - TCP поддерживает отправку одной квитанции на несколько пакетов сразу. Кроме того, насколько я помню, в TCP квитанции могут быть инкапсулированны в пакеты данных (хотя могу и ошибаться, кто помнит - поправьте)

Не успел отредактировать, уже ответ Спасибо. Но вопросы остаются. И добавился еще один - всегда ли квитанция приходит TCP пакетом?

Собственно ответный пакет и выступает. Точнее номер подтвержденного сегмента.
Так
Так
Да.
Только приблизительно. Мы можем получить одно подтверждение на несколько пакетов. Времена на их доставку будут разные.
Да. Можно считать, что время на доставку равно времени получения подтверждения минус время отправки пакета с сегментом. Причем пакетов с сегментами может быть несколько, а пакет с подтверждением - один.

Всегда, если только пакет не потерялся по дороге (тогда квитанции не будет)

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