Ao analisar uma interface de rede usando WireShark, o registro de data e hora de qual dispositivo é registrado?

Question

OK, isso pode parecer trivial, mas devido à natureza dos testes necessários para o meu aplicativo, preciso obter carimbos de data e hora precisos.

Estou usando o WireShark para analisar pacotes.

Suponha que eu tenha uma rede com 2 hosts h1 e h2.

h1 e h2 estão conectados uns com os outros através das interfaces h1-eth0 e h2-eth0, respectivamente.

Quando eu executo o Wireshark no host h1 para capturar a interface h1-eth0, posso ter certeza absoluta de que os timestamps que estão sendo gravados correspondem à hora do sistema do host h1?

Embora este seja o caso, além de suas observações úteis, seria realmente útil se eu conseguisse um link citando o mesmo (isso é apenas para que eu possa formalizar minha inscrição).

[OBSERVAÇÕES FINAIS]: manpage para o módulo timestamp do tcpdump. PCAP-TSTAMP .

NOTA: A página man é escrita pelo próprio Guy Harris. :)

Citações:

When capturing traffic, each packet is given a time stamp representing, for incoming packets, the arrival time of the packet and, for outgoing packets, the transmission time of the packet. This time is an approx‐ imation of the arrival or transmission time.

    

Answer 1

Suppose I have a network with 2 hosts h1 and h2.

h1 and h2 are connected with each other via interfaces h1-eth0 and h2-eth0 respectively.

When I run Wireshark on host h1 to capture the interface h1-eth0, can I be absolutely certain that the timestamps being recorded correspond to the system time of host h1?

Se você executar o Wireshark (ou tcpdump ou WinDump ou snoop ou Microsoft Network Monitor ou Sniffer ou OmniPeek ou Commview ou qualquer outro sniffer; a resposta não é específica do Wireshark ...) no host h1 , os pacotes são provenientes de um mecanismo de captura na pilha de rede do sistema operacional executado no host h1, e os registros de hora correspondem à hora em que o pacote foi marcado pela pilha de rede (isto é, com registro de data e hora pelo host h1) ou, em alguns casos, até o momento em que o pacote foi carimbado pelo adaptador de rede conectado ao host h1 (ou, no HP-UX, no momento em que a libpcap lê o pacote de a rede empilhar no host h1, já que o mecanismo de captura do HP-UX não possui pacotes de carimbo de data / hora).

Portanto, o registro de data e hora é o mais próximo do horário do host na máquina em que você está executando o programa do sniffer. Ele não corresponde necessariamente ao tempo exato, até o microssegundo ou nanossegundo, no qual o pacote chegou ao adaptador de rede do host h1 (a menos que o adaptador de rede esteja marcando os pacotes); apoiar isso). Pode haver um atraso entre o momento em que o pacote chegou ao adaptador de rede e a hora em que é marcado, o que poderia incluir:

• o tempo entre a chegada do pacote e a sinalização de uma interrupção para informar ao host que um pacote chegou (não há necessariamente uma interrupção sinalizada para cada pacote);
• o tempo entre a sinalização da interrupção e o host respondendo a ela;
• o tempo entre o host que está respondendo à interrupção e o pacote sendo entregue ao mecanismo de captura;
• o tempo entre o pacote sendo entregue ao mecanismo de captura e sendo marcado pelo mecanismo de captura.

Então, se por "posso ter absoluta certeza de que os registros de data e hora que estão sendo registrados correspondem à hora do sistema do host h1?" quer dizer "posso ter absoluta certeza de que os timestamps que estão sendo gravados correspondem, com alta precisão, à hora do sistema do host h1 no momento em que o pacote chegou?", a resposta é "não necessariamente, mesmo se você estiver executando no host h1 ". É mais próximo do momento em que o pacote chegou no host h1 do que no momento em que o pacote foi enviado do host h2, mas se você precisar saber valores de carimbo de data e hora de alta precisão e alta precisão, precisará de um especialista hardware que cronografa pacotes no adaptador de rede ou um caminho de código de recepção especialmente ajustado (o que pode significar que você tenha que hackear código de driver de interface e código de pilha de rede; esse caminho de código de recepção especialmente ajustado não é, por exemplo , uma opção de configuração para um kernel Linux ou uma opção de registro para um kernel do Windows).

(BTW, a resposta do Mitch se aplica apenas ao Windows; não existe rotina como KeQuerySystemTime no meu computador pessoal, por exemplo - os pacotes são marcados com um valor retornado por uma rotina chamada microtime .)

    

Answer 2

Tenha em mente que o Wireshark é o visualizador, o winpcap é o aplicativo de captura.

Com base no código e em uma postagem útil em sua lista de e-mails , o timestamp vem de KeQuerySystemTime em non -x86 sistemas e de uma combinação de KeQuerySystemTime e o rdtsc instruções sobre sistemas não-x86.

Independentemente disso, você deve ter uma precisão maior que 100 ns em relação ao clock do sistema.

Descrição oficial: link

    

Answer 3

Você simplesmente não consegue um registro de data e hora preciso ao capturar o tráfego de rede na configuração mencionada, devido ao seguinte:

• No Windows. Linux e FreeBSD você deve ter em mente que o registro de data e hora pode ser desativado facilmente em pelo menos alguns milissegundos (e até 10-25 ms) devido à carga na máquina host e à natureza da implementação do driver de rede e a NIC em si. Em particular, o processamento de interrupção de rede, bem como a alocação de memória e o outro processamento de interrupção de hardware (como a partir do seu disco rígido) contribuem para os atrasos. Reconhecendo esse problema, os sistemas operacionais modernos normalmente utilizam o processamento de interrupção de duas etapas. A divisão do processamento de interrupção em segmentos curtos e longos cria ainda mais confusão quanto à hora exata em que esse ou aquele pacote foi recebido por causa de todos os outros processos que precisam ocorrer na mesma máquina. Como resultado, você não tem certeza quanto a qualquer medição de tempo e é muito difícil ter qualquer tipo de exatidão ou precisão.
• Desvio do relógio. A menos que você tenha um hardware especializado, com o tempo, seus timestamps se desviarão. Por exemplo, depois de algumas horas ou dias, os registros de data e hora no host h1 e em h2 seriam diferentes em segundos ou mais. FYI: HPET drift de acordo com as especificações da Intel (outubro de 2004) é de 500 a 2000 ppm ou 0,05% a 0,2% e o RTC mais antigo é ainda pior.
• Se você tiver uma explosão de tráfego que exceda o número de buffers alocados pelo driver da NIC, poderá ocorrer perda de pacotes ou carimbo de hora incorreto devido ao controle de fluxo de hardware.

Simplificando, é muito difícil fazer o benchmark do host usando o winpcap em execução no mesmo host. Eu normalmente uso um dispositivo externo de captura de pacotes com um bom relógio, como o USC4060.