wireshark ponto de captura de pacotes [fechado]

1

Estou usando tc qdisc para adicionar atrasos aos pacotes na minha interface eth2 da seguinte forma

sudo tc qdisc add dev eth2 root netem delay 100ms 10ms 25%

Então eu pinguei um host e obtive algum resultado. Os resultados no terminal mostraram que o RTT foi de 74 ms, enquanto o RTT que calculei a partir do registro de data / hora do Wireshark é de aproximadamente 64 ms.

O que isso me sugere é que o Wireshark nos mostra os pacotes assim que da libpcap. A libpcap fica logo após a NIC e todos os atrasos de netem são adicionados somente depois que a libpcap tiver visto o pacote. Quanto ao resultado do terminal, o programa de ping vê o pacote após o atraso da netem e, assim, após mais 100 ms.

Existe alguma maneira de usar o Wireshark para ver os pacotes na camada de aplicativo ou após o atraso da netem.

Se o Wireshark não puder fazer isso, alguém pode me sugerir outras opções? Eu sei que posso usar outra caixa do Linux, fora da minha caixa em teste e atrasar na caixa externa. Mas eu preferiria evitar usar uma caixa Linux extra.

    
por Ashish Kurian 25.08.2017 / 17:07

1 resposta

1

O Wireshark deve ouvir em uma interface e não pode ver os pacotes na camada de aplicação.

Se você realmente precisa de uma ferramenta como o Wireshark, você pode fazer ping de uma VM ou de um contêiner e (no host) ter o Wireshark escutando na interface virtual ou na ponte que conecta essa VM à interface física. Você também pode simplesmente configurar um par veth se quiser evitar o ônus de criar uma VM.

Mas se tudo o que lhe interessa são os horários, strace pode ser suficiente com sua configuração atual:

# strace -r -T -e network ping 1.2.3.4
...
0.000113 sendmsg(...) = 64 <0.000032>
0.000055 recvmsg(...) = 84 <0.101680>
64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=101 ms
...

Entre colchetes angulares é o tempo gasto durante a chamada do sistema. Como o sendmsg é imediato (os bytes vão diretamente para as camadas inferiores de rede), o tempo que segue recvmsg mostra (aproximadamente) o tempo que levou para realmente enviar e receber as mensagens ping, ou seja, o RTT. >     

por 26.08.2017 / 00:51