Um segundo atraso antes do tcpdump retornar pacotes

Question

Usando o Ubuntu, estou tentando sincronizar o tcpdump sniffing com "pings" de auto-identificação de um dispositivo cliente. O problema é que a obtenção de partidas e paradas precisas é dificultada pelo que parece ser um atraso embutido no tcpdump. Aqui está a linha chave do meu script:

sudo timeout .5s tcpdump -i wlan0 -e

Quando defino o tempo limite para parar o tcpdump depois de, digamos, meio segundo (como no meu exemplo), nenhum pacote é retornado. Na verdade, qualquer valor menor que 1,1s falha ao retornar pacotes (enquanto 1,1 e mais funcionam maravilhosamente).

Eu tentei adicionar o argumento -n para suprimir o DNS, mas isso não fez diferença. Eu também tentei isso com duas placas wifi totalmente diferentes (Intel Centrino e TP-Link N900) para ter certeza de que não era apenas um "recurso" de hardware.

Eu não sou um desenvolvedor, mas usei o código-fonte do tcpdump para "delay", "latency" e "timeout", mas nada apareceu que parecesse responsável.

Alguma idéia?

    

Answer 1

gnu coreutils timeout.c tem um fallback para sistemas sem timer_settime () - ele irá reverter para resolução de um único segundo:

/* 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().  */

talvez seja esse o seu problema. Eu não corro ubuntu para que eu não posso verificar em primeira mão, mas por exemplo minha máquina openbsd só tem setitimer (), por isso só usaria timeouts full-segundo para mim

- editar: no segundo olhar ainda deve esperar pelo menos 1 segundo, a menos que seu arredondamento para baixo ... ou de alguma forma tcpdump está recebendo um sigterm cedo ... e talvez não haja apenas pacotes durante o intervalo?

    

Answer 2

A adição de -l às opções do tcpdump ajuda? Isso faz com que a saída padrão da linha tcpdump seja armazenada em buffer, de forma que cada linha é gerada assim que é recebida, em vez de armazenar em buffer mais dados antes da saída.

    

Answer 3

Por padrão, o tcpdump tentará executar pesquisas reversas de DNS nos endereços IP, que estão se comunicando. Um atraso de um segundo soa como um tempo limite razoável no caso de o tcpdump não obter uma resposta para essas pesquisas de DNS.

Adicionar -n à linha de comando tcpdump desativará as pesquisas de DNS. Isso ajuda se você alterar o comando para isso: sudo timeout .5s tcpdump -ni wlan0 -e

    

Answer 4

Não consigo reproduzir seu problema. Se eu iniciar ping -i 0.3 google.com e depois executar timeout .5s tcpdump -i wlan0 -e vejo o tráfego.

Tshark suporta a interrupção de uma captura sob diferentes condições, incluindo o tempo decorrido. Você poderia tentar

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

Se ambos mostrarem tráfego, o problema é provavelmente o que o kasperd sugere. Se o primeiro não mostrar tráfego, mas o segundo não, talvez o problema esteja no hardware da rede ou no driver.