[mschedrin]

Добрый день.

Задача. Снять сниффером на сервере отправляемый траффик. Снять на клиенте получаемый от сервера траффик, а затем сравнить их и понять сколько пакетов потеряно, сколько фрагментировано и т.п.

Понятно, что можно это сделать с помощью tcpdump, но уж очень проблематично, на мой взгляд. Может быть кто-нибудь знает более удобные утилиты для решения подобных задач. В идеале было видеть все изменения в реальном времени. Естественно основной интерес представляют *nix системы.

[XeonVs]

в wireshark что-то похожее было

Изменено 19 апреля, 2010 пользователем XeonVs

[jab]

 

wireshark - это ethereal для виндузятников, вообще-то

[qwertzy]

wireshark - это ethereal для виндузятников, вообще-то

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

Изменено 19 апреля, 2010 пользователем qwertzy

[s.lobanov]

>wireshark - это ethereal для виндузятников, вообще-то

 

эээ... вообще-то его просто переименовали(формально форкнули). Порт под винду тут ни при чём

[mschedrin]

Как эта функция называется в wireshark? Искал - ничего не нашел похожего.

Изменено 19 апреля, 2010 пользователем mschedrin

[voron]

tcpflow для снятия сессий может подойти лучше

[-Ars-]

Как эта функция называется в wireshark? Искал - ничего не нашел похожего.

Какая конкретно функция? Включаете сниффер - он начинает сниффить. Это то, что Вы просили. Или Вы чего-то недоговариваете? ;)

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

Ну, или и там, и там - tcpdump в текстовый файл и потом каким-нибудь diff-ом сравнивать. Это, конечно, будет не real-time...

[mschedrin]

tcpflow для снятия сессий может подойти лучше

Нужно сниффить udp траффик. С ним tcpflow работает? Судя по названию - нет :)

 

Как эта функция называется в wireshark? Искал - ничего не нашел похожего.

Какая конкретно функция? Включаете сниффер - он начинает сниффить. Это то, что Вы просили. Или Вы чего-то недоговариваете? ;)

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

Ну, или и там, и там - tcpdump в текстовый файл и потом каким-нибудь diff-ом сравнивать. Это, конечно, будет не real-time...

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

[loginrl103]

посмотри в сторону pcapdiff, tpcat. сравнивают два pcap файлы с двух "сторон"

[mschedrin]

посмотри в сторону pcapdiff, tpcat. сравнивают два pcap файлы с двух "сторон"

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

 

Если сравнивать два pcap файла обычным diff то могут вылезти пролемы с чексуммами. Если сетевуха отправителя сама рассчитывает чексуммы пакета, то в дампе мы увидим мусор вместо правильного CRC. Таким образом отличаться будут все пакеты, найти реальные отличия будет проблематично.

[loginrl103]

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

 

удп пакеты как-то нужно сопоставлять, для удп - чексумма самый надёжный вариант. pcapdiff - питон скрипт, сопоставление по crc можно заблокировать.

 

ps. в wireshark есть statistics -> conversation list -> udp. отображение полученных/переданных данных по ип/портам...

Изменено 20 апреля, 2010 пользователем loginrl103

[mschedrin]

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

 

удп пакеты как-то нужно сопоставлять, для удп - чексумма самый надёжный вариант. pcapdiff - питон скрипт, сопоставление по crc можно заблокировать.

 

ps. в wireshark есть statistics -> conversation list -> udp. отображение полученных/переданных данных по ип/портам...

Когда сетевая карта поддерживает расчет crc, то CPU уже не производит расчет суммы.

[loginrl103]

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

 

удп пакеты как-то нужно сопоставлять, для удп - чексумма самый надёжный вариант. pcapdiff - питон скрипт, сопоставление по crc можно заблокировать.

 

ps. в wireshark есть statistics -> conversation list -> udp. отображение полученных/переданных данных по ип/портам...

Когда сетевая карта поддерживает расчет crc, то CPU уже не производит расчет суммы.

это я знаю, вопрос был насчёт "Если сетевуха отправителя сама рассчитывает чексуммы пакета, то в дампе мы увидим мусор вместо правильного CRC" - почему crc должны быть разной для аппаратно и программно рассчитанных?

[UglyAdmin]

Потому что снифер получает исходящие пакеты ДО сетевой карты.

[loginrl103]

до сетевой карты? телепатически из воздуха?)

он получает карты ИЗ драйвера сетевой карты, ДО обработки пакетов сетевой подсистемой; crc должен быть одним и тем же в случае расчёта как программно так и аппаратно.

[voron]

2loginrl103

Речь об исходящем трафике. crc ещё не рассчитан, это сделает сетевая карта перед отправкой пакета.

[loginrl103]

а pcap точно сработает до расчёт crc?

[cant]

Задача. Снять сниффером на сервере отправляемый траффик. Снять на клиенте получаемый от сервера траффик, а затем сравнить их и понять сколько пакетов потеряно, сколько фрагментировано и т.п. ...

С таким общим подходом придется разрабатывать собственный универсальный инструмент (например, на основе известных утилит).

Чтобы правильно подобрать или создать инструмент надо уточнить суть проблемы. К примеру может и iperf будет достаточно чтобы локализовать неисправность.

 

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

[mschedrin]

Задача. Снять сниффером на сервере отправляемый траффик. Снять на клиенте получаемый от сервера траффик, а затем сравнить их и понять сколько пакетов потеряно, сколько фрагментировано и т.п. ...

С таким общим подходом придется разрабатывать собственный универсальный инструмент (например, на основе известных утилит).

Чтобы правильно подобрать или создать инструмент надо уточнить суть проблемы. К примеру может и iperf будет достаточно чтобы локализовать неисправность.

 

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

Суть проблемы. Доставка мультикаста от стримера до клиента через транзитного провайдера проходит не совсем гладко. Потерь через unicast нет. Нужно разобраться - либо это стример что-то неправильно отсылает либо в сети провайдера что-то происходит не так. Если предложите что-то более простое и настолько же надежное - буду рад. Вариант приехать с ноутом к стримеру и воткнуться в него напрямую не предлагать.

[cant]

Суть проблемы. Доставка мультикаста от стримера до клиента через транзитного провайдера проходит не совсем гладко. ...

Тогда Вам сюда

http://forum.nag.ru/forum/index.php?showtopic=52471

 

[shuras]

На самом деле проблем нет. Делаете дампы. Потом преобразуете их в текстовый формат тем же tcpdump'ом на одном компе (чтобы не было разных форматов от разных версий) убрав временную информацию. Итого два текстовых файла. Сравниваете каким нибудь визуальным diffом под виндой. Ну или натуральный diff под никсами. Места расхождения покажет.

[voron]

2loginrl103

а pcap точно сработает до расчёт crc?

для исходящих данных с offload tx-checksumming: on конечно до расчёта.

Изменено 22 апреля, 2010 пользователем voron