LINUX.ORG.RU

В tcpdump есть, в recvfrom - нет

 , ,


0

3

Есть две машины - А и Б. Программа отправляет с А udp-пакет на Б и уходит ждать ответа на recvfrom. Пакет на Б успешно принимается и на него посылается ответ. Ответ, в большинстве случаев, в программе на А не появляется и recvfrom продолжает спокойно висеть, будто ничего не приходило. Одновременно, на той же машине А запущен tcpdump, согласно которому ответ дошёл. Далее, Б может посылать запросы на А, которые тоже почти всегда остаются незамеченными recvfrom, но при этом все они видны в дампе.

Что может быть причиной такого поведения? Почему tcpdump видит, а recvfrom нет?

PS Та же самая пара программ тестировалась на других машинах и там проблем не было.

Декабрь же... В это время года часто ветром сдувает udp-пакеты в сторону от recvfrom. Нужно посмотреть на ваш код, возможно вы не учитваете погодный фактор.

not_rj45 ()

у тебя там случайно не передается 100500 пакетов за секунду?

udhv ()

tcpdump видит пакеты до фильтрации и до обработки пакета протоколами.

Если А начинает видить ответы при запущеном tcpdump - значит проблема в mac-адресах. Запусти tcpdump -nvei ethx udp and port XXXX, а еще на контрольные суммы входящих пакетов желательно обратить внимание.

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)

А там обычный udp или udp multicast?

pon4ik ★★★★★ ()
Ответ на: комментарий от vel

Запустил tcpdump с этими аргументами, ситуация такая же - большинство пакетов теряется, но некоторые всё же доходят. Дошедшие от недошедших отличаются только параметром Identification на уровне IP и контрольной суммой заголовка, как следствие. MAC-адреса источника и приёмника одни и те же.

aldaril_kote ()

почти всегда
почти

Вот это очень странно. То есть часть пакетов все-таки приходит? Пакеты небольшие, меньше MTU?

А с каким интервалом проходят(именно принимаются) пакеты? И как физически связаны А и Б? В одном эзернет-сегменте или проходят через маршрутизатор?

iptables (на А) не может случайно блокировать?

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Пакеты по 55 байт, MTU 1500

Интервал между принятыми пакетами может быть каким угодно. Например, при последнем запуске за 10 секунд было послано 12 пакетов, из них дошли только два. Потом Б затих на минуту и снова послал 10 пакетов, из которых не был принят ни один. Далее эта история повторилась и только в следующем заходе были приняты два из 10 посланных.

Машины находятся в одной сети в одном офисе, tracepath говорит Resume: pmtu 1500 hops 1 back 1

В iptables --list пусто.

aldaril_kote ()

ping пакеты не теряет ? А ssh работает ?

Попробуй это Python-скрипт вместо клиента заюзать, если он ответы терять не будет, дело скорее всего в инициализации сокета:

import socket
import sys
import time

# Create a UDP socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

num_data_repetions_in_msg = 30
count = 0

# Specify your server address and port here
server_address = ('192.168.1.200', 10000)

while True:
    msg = '[Seq  %03d]' % count + ('[MSG  %03d]' * (num_data_repetions_in_msg-1) % tuple(range(num_data_repetions_in_msg-1)))
    try:
        # Send data
        print >>sys.stderr, 'sending "%s"' % msg
        sent = sock.sendto(msg, server_address)

        # Receive response
        print >>sys.stderr, 'waiting to receive'
        data, server = sock.recvfrom(4096)
        print >>sys.stderr, 'received "%s"' % data
        count += 1
    except:
        break

    time.sleep(1)

print >>sys.stderr, 'closing socket'
sock.close()
alx777 ()
Ответ на: комментарий от aldaril_kote

Не очень прояснилось.

Ну, я бы начал проверять по очереди - сеть, потом приложение. Можно неткатом (nc) пускать и ловить UDP-пакеты. С А на Б, потом с Б на А. Если пакеты будут ходить без потерь, значит что-то в приложении

Deleted ()
Ответ на: комментарий от aldaril_kote

Посмотри, может чем то отличаются udp заголовки потерянных пакетов?

Не через туннель ходят пакеты?

pon4ik ★★★★★ ()
Ответ на: комментарий от aldaril_kote

А на какой адрес шлются пакеты?

И, есть ли нужные данные в тех пакетах которые дошли?

Попробуй проиграть дамп с помощью udpreplay, посмотри придут ли пакеты на локалхосте.

pon4ik ★★★★★ ()
Ответ на: комментарий от alx777

С этим скриптом всё то же, что с моим клиентом - большую часть пакетов он не видит.

aldaril_kote ()
Ответ на: комментарий от aldaril_kote

А что с ping'ом ? Пакеты не теряются ?

Что говорят «ethtool -S имя-интерфейса» и «ifconfig имя-интерфейса» ?

alx777 ()

dnat во внутреннюю сеть без snat?

//router

anonymous ()
Ответ на: комментарий от aldaril_kote

А nc/socat уже попробовал как рекомендовали до этого? Т.е. просто в цикле шли циферки например с префиксом в n байт, что бы было похоже на твой пэйлоад и легко было детектировать гэп. Т.е. и сервер и клиент надо заменить на nc и слать на тот же адрес:порт.

Заголовки udp-пакетов одинаковы

На всякий случай уточню - имелась ввиду разница между потерянными и полученными пакетами, криво изъяснился прошлый раз.

pon4ik ★★★★★ ()
Ответ на: комментарий от aldaril_kote

отличаются только параметром Identification на уровне IP и контрольной суммой заголовка

Покажи пример одного дошедшего и одного недошедшего из дампа (tcpdump -nvei .....)

vel ★★★★★ ()
Ответ на: комментарий от vel

Похоже, нашли причину проблемы - на той стороне неправильно считали контрольную сумму заголовка IP.

aldaril_kote ()
Ответ на: комментарий от aldaril_kote

Похоже, нашли причину проблемы - на той стороне неправильно считали контрольную сумму заголовка IP.

т.е. на отправляющей стороне сокет в raw режиме и все заголовки генерятся твоим софтом, а не ядром?
и в стартовом посте об этом ни слова — клево, че!

anonymous ()
Ответ на: комментарий от anonymous

Софт не мой, но заголовки генерятся им самим. Я был убеждён, что проблема на стороне А, потому и забыл упомянуть этот факт.

aldaril_kote ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.