web-dev-qa-db-ja.com

クライアントが応答しないTCP SYN-ACKパケットイーサネットドライバ

私はイーサネットドライバを開発し、TCP交換コードを実装しています。私のTCPコードをテストするには、これがシナリオです(wiresharkで監視されます):

サーバー:カスタムイーサネットデバイス

クライアント:PC

  1. HerculesユーティリティからTCPクライアントソケットを開きました。
  2. イーサネットデバイスとHerculesからのARP要求と応答の交換を確認できます。
  3. ARP要求が処理された後、クライアントはTCP SYNパケットを送信し、サーバーはSYN-ACKで応答します。
  4. 3ウェイハンドシェイクを完了するには、クライアントは取得していない最後にACKを送信する必要があり、HerculesはTCP接続がタイムアウトしました。

クライアントが3ウェイハンドシェイクを完了するためにSYN-ACKを確認しない理由の考えられる問題を診断する必要があります。

TCP SYN ACK packet exchange image

2
RAJ JOHRI

クライアントまたはサーバーのどこでキャプチャしていますか?クライアントでキャプチャしている場合は、「編集->設定->プロトコル-> IPv4->可能であればIPv4チェックサムを検証する」

サーバーのSYN/ACKパケットのIPヘッダーチェックサムが0であるため、無効であるように見えます。その場合は、計算する必要があります。そうしないと、クライアントマシンはIPパケットを無効としてドロップします。

クライアントでキャプチャしていて、SYNパケットのクライアントのIPヘッダーチェックサムが0の場合、Wiresharkが示すように、クライアントマシンが「IPチェックサムオフロード」用に構成されており、Wiresharkが前にパケットを受信して​​いることが原因である可能性があります。チェックサムはハードウェアによって計算されます。

本当に何が起こっているのかを知りたい場合は、SPANポートまたはTAPを使用して別のマシンでキャプチャする必要があります。そうすれば、適切なチェックサムが計算されたパケットを受信できます。キャプチャの詳細については、Wiresharkの イーサネットキャプチャセットアップ wikiページ、またはJasper Bongertzの非常に役立つ6部構成のネットワークキャプチャプレイブック( パート1-))を参照してください。 Ethernet Basics 彼の記事の別の1つを参照しています ローカルパケットキャプチャの欠点

2