質問

pingエコーを検証する場合、ユーティリティ/ライブラリはしばしばパケットのチェックサムのみをチェックし、送信されたペイロードが返されたペイロードと一致することを実際に確認しないようです。たとえば、WiresharkのICMPパーサーは不正なチェックサムのみをチェックします。Rubyの net- ruby もチェックします。

低レベルのネットワークドライバーの問題をデバッグしています。受信時にデータが破損していないことを確認する必要があるため、 ICMPエコー。ただし、チェックサムがエコー応答に含まれるデータと一致する可能性がある一方で、エコー応答のデータがエコー要求のデータと一致しない可能性があるため、既存のPingツールでは不十分です。したがって、どちらにも有効なチェックサムがあります(チェックサムコードにエラーはありません)が、データ受信部分にエラーがあり、ホストが送信していると考えているものをドライバーが受信していません。

エコーペイロードをチェックして、送信したものと同じであることを確認するにはどうすればよいですか?スタンドアロンの「paranoid ping」が存在する場合私が使用できるユーティリティ、それも大丈夫です-ネットワークのフラッディング時にのみ問題が発生しているので、pingの長さと周波数を変更できる必要があります。

Rubyライブラリ/スニペットの形式で使用したいのですが、Windowsで実行できるようにすすめることができる限り、任意の言語またはスタンドアロンアプリを使用できます。

ありがとう!

役に立ちましたか?

解決 2

@Tom:答えてくれてありがとう。あなたは言った:

  

受信者はデータからチェックサムを再計算し、送信されたものと比較します。

しかし、あなたはまた言った:

  

ICMPチェックサムにはTCPヘッダーは含まれず、ICMPタイプ、コード、チェックサム、およびデータフィールドのみが含まれます。

ICMPタイプは、エコー要求/応答で異なります(1つは0で、もう1つは8だと思います)。そのため、定義上(実際には、Wiresharkを覗くと)、ICMPチェックサムは送信要求とエコー応答の間で一致しません。

私の問題は、pingユーティリティ/ライブラリが何かをチェックした場合(そして多くの場合チェックしなかった)、チェックサムがデータと一致することを確認するためだけにチェックすることでした。 2つのペイロードが同一であることを確認するために、エコーされた応答で送信されたデータを実際に確認する人はほとんどいないようです。リクエストとレスポンスの両方に有効なチェックサムがあり、ペイロードが異なる可能性があり、私が見たほとんどのPingルーチンはそのような状態をチェックしていない可能性があります(しかし、それはたまたま私のバグの一種です現在のデバイス)。

私の質問をご覧いただきありがとうございます。ありがとうございました。

@All:

自分の質問に答えて、堅牢な。Net Ping クラス。これにより、受信した応答バッファーにすぐにアクセスできます(他のほとんどのPingライブラリとは異なります)。

他のヒント

チェックサムのポイントが欠落していると思います。チェックサムの目的は、データが完全であることを検証することです。送信者は、データからチェックサムを計算し、データとともに送信します。受信者はデータからチェックサムを再計算し、送信されたものと比較します。それらが一致しない場合、データは損なわれていないか、2つのうちの1つが間違って計算しています。多くの場合、不正なチェックサムは、壊れたプロトコルスタックが多数あるためパケットをドロップしません。もちろん、パケットマングラーもチェックサムを修正しませんが、両方が適切にチェックサムをチェックした場合、チェックサムチェックデータが無傷であることを示します。

TCPチェックサムまたはICMPチェックサムを見ていますか? ICMPチェックサムにはTCPヘッダーは含まれず、ICMPタイプ、コード、チェックサム、およびデータフィールドのみが含まれます。 TCPチェックサムの失敗は、必ずしもICMPの内容が完全ではないということではなく、TCPヘッダーが(おそらく壊れたNATによって)混乱していることを意味する可能性があります。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top