Come controllare il contenuto del pacchetto di ritorno in ICMP Ping / Echo?

Question

Quando si convalida l'eco del ping, sembra che le utilità / librerie spesso controllino solo il checksum del pacchetto e non confermino effettivamente che il payload inviato corrisponda al payload che è stato restituito. Ad esempio, il parser ICMP di Wireshark controlla solo i checksum errati, e questo è tutto ciò che net- di Ruby rubini pure.

Sto eseguendo il debug di un problema del driver di rete di basso livello e devo confermare che i dati non vengono alterati quando vengono ricevuti, quindi voglio testare il mio driver utilizzando una richiesta di basso livello come ICMP Echo . Tuttavia, i miei strumenti Ping esistenti non sono sufficienti, poiché temo che mentre il checksum può corrispondere ai dati contenuti nella risposta dell'eco, i dati nella risposta dell'eco non corrispondono ai dati nella richiesta dell'eco. Quindi, anche se entrambi hanno checksum validi (non c'è errore nel codice di checksum), c'è un errore nella porzione di ricezione dei dati, in modo che il mio driver non riceva ciò che l'host pensa che stia inviando.

Come posso controllare il payload dell'eco per confermare che è lo stesso di quello che ho inviato? Se esiste un ping paranoico standalone " utilità che potrei usare, va bene lo stesso - ho solo bisogno di essere in grado di variare le lunghezze e le frequenze del ping poiché vedo il problema solo quando la rete è allagata.

Lo preferirei sotto forma di libreria / snippet di Ruby, ma qualsiasi lingua o app standalone è accettabile, a condizione che riesca a farlo funzionare su Windows.

Grazie!

Answer 1

@ Tom: grazie per la risposta. Hai detto:

  

Il destinatario calcola nuovamente un checksum dai dati e lo confronta con quello che è stato inviato.

Ma poi hai anche detto:

  

Il checksum ICMP non include le intestazioni TCP, ma solo i campi tipo ICMP, codice, checksum e dati.

Il tipo ICMP è diverso tra la richiesta / risposta dell'eco (uno è 0, l'altro è credo 8). Quindi per definizione (e in pratica, se dai un'occhiata a Wireshark) i checksum ICMP non corrispondono tra la richiesta di invio e la risposta dell'eco.

Il mio problema era che se le utilità / librerie di ping controllavano qualcosa (e spesso non lo facevano), controllavano solo per assicurarsi che il checksum corrispondesse ai dati. Sembra che solo raramente le persone controllino effettivamente i dati inviati con la risposta eco per assicurarsi che i due payload siano identici. È possibile che sia una richiesta che una risposta possano avere checksum validi, ma payload diversi e la maggior parte delle routine di ping che ho visto non hanno verificato tale condizione (ma capita che sia il tipo di bug che sto riscontrando sul mio dispositivo al momento).

Grazie per aver esaminato la mia domanda e aver risposto, è molto apprezzato.

@All:

In risposta alla mia domanda, sono stato in grado di utilizzare il robusto . Net Ping , poiché mi dà accesso immediato al buffer di risposta ricevuto (a differenza della maggior parte delle altre librerie Ping che ho trovato).

Answer 2

Penso che ti stia perdendo il punto del checksum. Lo scopo del checksum è di verificare che i dati siano intatti. Il mittente calcola il checksum dai dati e lo trasmette con i dati. Il destinatario calcola nuovamente un checksum dai dati e lo confronta con quello inviato. Se non corrispondono, i dati non sono intatti o uno dei due lo sta calcolando in modo errato. Molto spesso i checksum errati non provocano la caduta di pacchetti perché ci sono un sacco di stack di protocolli rotti là fuori, e ovviamente mangler di pacchetti e che non risolvono il checksum, ma se entrambe le parti lo fanno correttamente allora il check di checksum ti dice che i dati sono intatti.

Stai guardando il checksum TCP o il checksum ICMP? Il checksum ICMP non include le intestazioni TCP, ma solo i campi tipo ICMP, codice, checksum e dati. Un errore di checksum TCP non significa necessariamente che i contenuti dell'ICMP non siano intatti, potrebbe solo significare che le intestazioni TCP sono state danneggiate (da un NAT rotto, forse).