web-dev-qa-db-ja.com

間違ったチェックサムでTCP

OpenStackマシンに大きなファイルを送信するのに問題があります。

私たちのインターネット接続はLTEを超えているため、不良パケットが予想されます。ただし、TCPを介してデータを送信しても、数MBを送信するとデータが破損します。

TCPチェックサムが実際に検証されているかどうかをテストしたいので、無効なチェックサムを含むTCPパケットを送信するツールが必要です。

任意のIPパケットを送信できるプログラムもありますが、接続も開始する（三者ハンドシェイクなどを行う）ツールがいいと思います。

次に、tcpdumpを使用して、サーバーがパケットにACKを送信するか、再送信を要求するかを確認できます。 （ツールがこれも実行できる場合は、さらに優れています。）

いくつかの考えと注意：

  • クライアントとサーバーの両方で異なるLinuxバージョンを試しました。
  • （低速の）DSL回線に切り替えるときに破損したパケットがなくなりました。
  • 別のホストから別のサーバーに送信するときに、破損したパケットはありません。
  • クライアントとサーバーの両方からのTCP送信のtcpdumpがありますが、OpenStackホストはそれらを調べたくないので、チェックサムが問題であるかどうかを調べたいのです。また、ホスト用のテストプログラムもあります。
  • サーバーはOpenStack環境のインスタンスです。
  • Linuxカーネルの最近のveth TCPチェックサム破損のバグがこのバグを説明します。

これをデバッグする方法の他のアイデアも歓迎します。

linuxnetworkingtcptcpip
2
close2

https://github.com/kubernetes/kubernetes/issues/18898

これを行う方法を説明します。

ここに（短縮された）バージョンがあります：

受信側のマシンでnc -l -p 12345を実行します

送信側のマシンで(i=0; while true; do echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa $i; i=$((i+1)); sleep 1; done) | netcat IP_OF_RECEIVING_MACHINE 12345を実行します

パッケージを破損するには、送信側のマシンで次のコマンドを実行します。

Sudo tc qdisc add dev eth0 root netem corrupt 100%; sleep 10; Sudo tc qdisc del dev eth0 root netem

10秒間、eth0のすべてのパッケージが破損することに注意してください。

チェックサムが正しく機能する場合、10秒間テキストを受信せず、すぐに受信します。ただし、チェックサムが機能しない場合は、テキストが破損します。

1
close2

  • Hping、hping3などのパケット作成ツールを使用できます。下のリンクを確認してください。とても便利です。

    hping3の例

    上記のリンクから、これがあなたが探しているものだと思います。

    -b --badcksum（しよう）不正なIPチェックサムでパケットを送信する多くのシステムは、パケットを送信するIPチェックサムを修正するため、代わりに不正なUDP/TCPチェックサムを取得します。

  • プログラミングスキル（ソケットプログラミング、Linux上のBSDソケット、グーグルできます）がある場合は、rawソケットを使用してダミーのtcpパケットを送信し、構築することができます独自のトランスポート層パケット。

0
Levent Divilioglu