Отсутствие фрагментов UDP при мониторинге трафика с помощью tcpdump - PullRequest
Новая
       35

Отсутствие фрагментов UDP при мониторинге трафика с помощью tcpdump

3 голосов
/ 25 августа 2009

Я нахожусь в локальной сети только с 8 подключенными компьютерами, использующими гигабитный коммутатор Netgear с 24 портами, нагрузка на сеть очень низкая, и буферы отправки / получения на всех задействованных узлах (работающие в Slackware 11) установлены в 16 МБ. Я также запускаю tcpdump на каждом узле для отслеживания трафика.

Отправляющий узел отправляет большой UDP-пакет размером 10044 байта, который чаще всего (3/4 раза) не попадает в приложение принимающей стороны, в этих случаях я замечаю (используя tcpdump), что первые x фрагменты отсутствуют и только последние 3 (все со смещениями> 0 и по порядку) перехватываются tcpdump. Таким образом, фрагментированный пакет UDP не может быть повторно собран и, скорее всего, выброшен.

Я нахожу пропущенные фрагменты странными, поскольку я также пытался провести простой нагрузочный тест с разгрузкой 10000 UDP-сообщений одинакового размера, принимающее приложение отправляет ответ, и все тесты до сих пор возвращают 100% ответов.

Есть подсказки или подсказки?

1 Ответ

1 голос
/ 08 февраля 2010

Обновление!

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

Используя windump на машине-отправителе Windows и tcpdump на машине-получателе, после некоторого простоя приложения (~ 5 минут) я попытался отправить сообщение udp, но в итоге получил только один фрагмент, перехваченный windump и tcpdump, 3 оставшихся фрагмента потеряны. Отправка того же сообщения еще раз работает нормально, и стенд windump и tcpdump перехватывает все 4 фрагмента, и приложение на принимающей стороне получает сообщение. Шаблон повторяется.

Начал поиск и нашел следующую информацию, но мне все еще не дан четкий ответ.

http://www.eggheadcafe.com/software/aspnet/32856705/first-udp-message-to-a-sp.aspx

Пересматривая журналы Теперь я замечаю, что отправляется запрос / ответ ARP, что соответствует одной из идей, приведенных в ссылке выше.

ВНИМАНИЕ! Я фильтрую windump на отправляющей стороне, используя: "dst host receivernode"

Захват из windump: первое неудачное сообщение udp, должно быть длиной 4 фрагмента 

14:52:45.342266 arp who-has receivernode tell sendernode
14:52:45.342599 IP sendernode> receivernode : udp

Capture from windump: второе сообщение udp, точно такое же содержимое, все 4 фрагмента перехвачены 

14:52:54.132383 IP sendernode.10104 > receivernode .10113: UDP, length 6019
14:52:54.132397 IP sendernode> receivernode : udp
14:52:54.132406 IP sendernode> receivernode : udp
14:52:54.132414 IP sendernode> receivernode : udp
14:52:54.132422 IP sendernode> receivernode : udp
14:52:56.142421 arp reply sendernode is-at 00:11:11:XX:XX:fd (oui unknown)

Кто-нибудь, кто имеет хорошее представление о том, что происходит? пожалуйста, уточните!

...