2

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

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

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

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

ありがとう！

4

2 に答える 2

1

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

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

于 2008-11-26T20:37:08.073 に答える
0

@トム：答えてくれてありがとう。あなたが言った：

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

しかし、あなたは次のようにも言いました。

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

エコーリクエスト/レスポンスでICMPの種類が違います(片方は0、もう片方は8だと思います)。そのため、定義上 (そして実際に Wireshark をのぞいてみると)、送信要求とエコー応答の間で ICMP チェックサムが一致しません。

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

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

@全て：

私自身の質問への回答として、堅牢な.Net Pingクラスを使用することができました。これは、受信した応答バッファーにすぐにアクセスできるためです (私が見つけた他のほとんどの Ping ライブラリとは異なります)。

于 2008-11-26T21:48:51.470 に答える