Como verificar o conteúdo do pacote de retorno no ICMP Ping / eco?

Question

Ao validar pingue eco de, parece que utilitários / bibliotecas, muitas vezes só verificar o checksum do pacote, e não fazer realmente confirmar que a carga enviado corresponde à carga que foi devolvido. Por exemplo, analisador ICMP do Wireshark apenas verifica checksums ruim, e isso é tudo o que Ruby NET- rubi cheques também.

Estou a depuração de um problema de driver de rede de baixo nível, e eu preciso para confirmar que os dados não estão sendo mutilado, quando recebeu, então eu quero testar o meu motorista usando um pedido de baixo nível, como ICMP echo. No entanto, minhas ferramentas de Ping existentes são insuficientes, porque temo que, enquanto a soma de verificação pode coincidir com os dados contidos na resposta de eco, os dados da resposta de eco não coincide com os dados no pedido de eco. Assim, mesmo que ambos têm checksums válidos (não há nenhum erro no código de verificação), há um erro nos dados recebem parcela, de tal forma que o motorista não está recebendo o que o anfitrião pensa que está enviando.

Como pode verificar a carga de eco para confirmar que é o mesmo que eu enviei? Se há um autônomo "ping paranóico" utilitário que eu poderia usar, tudo bem também - Eu só preciso ser capaz de variar os comprimentos de ping e freqüências como eu só estou vendo o problema quando a rede de inundado.

Eu prefiro-o na forma de uma biblioteca Ruby / trecho, mas qualquer app língua ou autônomo é aceitável, há tanto tempo quanto eu posso encaixar-lo em execução no Windows.

Obrigado!

Answer 1

@ Tom: Obrigado pela resposta. Você disse:

O receptor re-calcula uma soma de verificação a partir dos dados e compara-o ao que foi enviado.

Mas então você também disse:

A soma de verificação ICMP não inclui os cabeçalhos TCP, apenas o tipo ICMP, código, soma de verificação e campos de dados.

O tipo ICMP é diferente entre o pedido de eco / resposta (um é 0, o outro é que eu acho 8). Então, por definição (e, na prática, se você dar uma olhada com Wireshark) as somas de verificação ICMP não correspondem entre o pedido de envio e a resposta de eco.

Meu problema era que, se os utilitários de ping / bibliotecas verificado qualquer coisa (e muitas vezes eles não o fizeram), eles só verificado para se certificar de que a soma de verificação combinados os dados. Parece que só raramente é que as pessoas realmente verificar os dados enviados com a resposta echo'd para se certificar de que as duas cargas úteis são idênticos. É possível que tanto um pedido e uma resposta pode ter somas de verificação válidas, mas diferentes cargas, e maioria das rotinas de Ping que eu vi não tenho verificado para tal condição (mas ele passa a ser o tipo de bug que estou tendo no meu dispositivo no momento).

Obrigado por olhando para a minha pergunta e respondendo embora -. É muito apreciado

@All:

Em resposta à minha pergunta, eu era capaz de usar o robusto . Ping Net classe, como ele me dá acesso pronto para o buffer de resposta recebida (ao contrário da maioria outras bibliotecas Ping eu encontrei).

Answer 2

Eu acho que você está perdendo o ponto da soma de verificação. O objetivo da verificação é validar que os dados estão intactos. O remetente calcula a soma de verificação a partir dos dados e transmite-o com os dados. O receptor re-calcula uma soma de verificação a partir dos dados e compara-o ao que foi enviado. Se eles não corresponderem, em seguida, os dados não está intacta ou um dos dois está calculando errado. Na maioria das vezes somas de verificação inválidas não resultam em pacotes descartados porque há muitas pilhas de protocolo quebrados lá fora, e, claro, manglers pacotes e que não arrumar o checksum, mas se ambos os lados fizer acontecer para fazê-lo corretamente, então a verificação de checksum diz-lhe que os dados estão intactos.

Você está olhando para a soma de verificação TCP ou a soma de verificação ICMP? A soma de verificação ICMP não inclui os cabeçalhos TCP, apenas o tipo ICMP, código, soma de verificação e campos de dados. checksum falha A TCP não significa necessariamente o conteúdo ICMP não estão intactos, isso poderia significar apenas que os cabeçalhos TCP foram desordenado com (por um NAT quebrado, talvez).