Назад | Перейти на главную страницу

Задержка в одну секунду перед тем, как tcpdump вернет пакеты

Используя Ubuntu, я пытаюсь синхронизировать сниффинг tcpdump с самоидентифицирующимися «пингами» с клиентского устройства. Проблема в том, что получение точных запусков и остановок затруднено тем, что выглядит как встроенная задержка в tcpdump. Вот ключевая строка моего сценария:

sudo timeout .5s tcpdump -i wlan0 -e

Когда я устанавливаю тайм-аут для остановки tcpdump, скажем, через полсекунды (как в моем примере), пакеты не возвращаются. Фактически, любое значение ниже 1,1 с не возвращает пакеты (в то время как 1,1 и больше работают отлично).

Я пробовал добавить аргумент -n для подавления DNS, но это не имело значения. Я также попробовал это с двумя совершенно разными Wi-Fi-картами (Intel Centrino и TP-Link N900), чтобы убедиться, что это не просто аппаратная «функция».

Я не разработчик, но я нашел в исходном коде tcpdump «задержку», «задержку» и «тайм-аут», но ничего не вышло, что казалось бы ответственным.

Любые идеи?

Добавляет -l в помощь tcpdump options? Он делает стандартный вывод строки tcpdump буферизированным, так что каждая строка выводится сразу после ее получения, вместо буферизации дополнительных данных перед выводом.

gnu coreutils timeout.c имеет запасной вариант для систем без timer_settime () - он вернется к разрешению в одну секунду:

/* timer_settime() provides potentially nanosecond resolution.
setitimer() is more portable (to Darwin for example),
but only provides microsecond resolution and thus is
a little more awkward to use with timespecs, as well as being
deprecated by POSIX.  Instead we fallback to single second
resolution provided by alarm().  */

возможно, это ваша проблема. Я не запускаю ubuntu, поэтому я не могу проверить из первых рук, но, например, моя машина openbsd имеет только setitimer (), поэтому для меня будут использоваться только тайм-ауты на полную секунду

--edit: при втором взгляде он все равно должен подождать не менее 1 секунды, если только его округление в меньшую сторону ... или каким-то образом tcpdump получает ранний сигнал ... и, может быть, в течение интервала просто нет пакетов?

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

Добавление -n в командную строку tcpdump отключит поиск DNS. Помогает ли, если вы измените команду на эту: sudo timeout .5s tcpdump -ni wlan0 -e

Я не могу воспроизвести вашу проблему. Если я начну ping -i 0.3 google.com а затем запустить timeout .5s tcpdump -i wlan0 -e Я вижу движение.

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

tshark -a duration:1 -i wlan0
tshark -a duration:2 -i wlan0

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