私は大量のTCP / IPトラフィックを送信するデバイスを使用してきました。
Pythonプログラミング言語を使用してLinuxシステム（Ubuntu 22.04.2 LTS）でこれらのパケットをキャプチャしようとしています。
ただし、ほとんどの場合、送信されたパケットはオペレーティングシステムで正しく受信されません。
これらのパケットの一部はオペレーティングシステムで正しく再組み立てされますが、ほとんどはそうではありません。
Wiresharkの内容をはっきりと見ることができます。
以下は予期しない動作です。
私が主に見ているのは断片化されたIPプロトコルパケットであり、それからTTL（断片化タイムアウト）を超えたことを見ます。
予想される動作は次のとおりです。
すべてのパケットをキャプチャするためにこの動作を修正する方法（パケット再組み立て失敗を引き起こす条件緩和）はありますか？
Windows 10では、このような問題が発生したことはありません。
同じクライアントシステムでUbuntuからログアウトしてWin10にログインすると、パケットは破棄されずに送信されたすべてのチャンクが再構築され、適切なポートに送信されます。 Linuxでは、パケット損失に影響を与えるいくつかのシステムパラメータがあるようです。
以下にWiresharkキャプチャファイルを添付しました。
https://drive.google.com/file/d/1GFtlHnKF619HE02JfuSUQpIGqSxRt6Yf/view?usp=sharing
これが出力ですsudo sysctl -a | grep ipfrag
net.ipv4.ipfrag_high_thresh = 4194304
net.ipv4.ipfrag_low_thresh = 3145728
net.ipv4.ipfrag_max_dist = 64
net.ipv4.ipfrag_secret_interval = 0
net.ipv4.ipfrag_time = 30
また、次の操作を試しました（上記の設定の10倍）。
sudo sysctl -w net.ipv4.ipfrag_time=300
sudo sysctl -w net.ipv4.ipfrag_high_thresh=41943040
sudo sysctl -w net.ipv4.ipfrag_low_thresh=31457280
sudo sysctl -w net.ipv4.ipfrag_max_dist=640
まだ運がありません。
ありがとうございます。
ベストアンサー1
何らかの理由で一部の部品が欠落しています。
これは再組み立ての問題ではなく、時間制限をいくら調整しても問題は解決しません。
Wireshark（またはすべてのpcapベースのツール）で見られるのは、オペレーティングシステムのネットワークスタックに渡される前にNICに入って来る生のトラフィックです。したがって、キャプチャに欠落しているエントリがあるたびに、NICはそのエントリを受信できなかったことを意味します（または単にハードウェアによって削除されたエントリです）。
最初のスクリーンショットは、ダンプに1つ以上のフラグメント（オフセット17760のフラグメント）がないことを示しています。したがって、オペレーティングシステムは、フラグメントが到着する可能性がある場合（転送中に並べ替えられたか、下位層で再送信された場合）をしばらく待ち、フラグメントが到着しないとICMP再アセンブリタイムアウトエラーが発生します。
プライマリネットワークによってパケットが長時間遅延することが予想される妥当な理由がなければ、タイムアウトを操作する必要はありません。それらは失われただけで決して現れず、長く待っても役に立ちません。
これがまさに信頼できない伝送に基づくUDPの現実です。メディアに重大な損失があり、断片化が多い場合、多くのパケットを再組み立てすることはできません。
まず、パケット損失の原因が何であるかを調べる必要があります。 NICのエラーカウンタをチェックするのが良い最初のステップかもしれません。同じハードウェアを使用する他のオペレーティングシステムでこの問題が発生しない場合は、ネットワークカードが異なるように設定されている可能性があります（たとえば、オフロードが無効になっているため、CPUがトラフィックを処理できなくなったり、ネットワークカードが1つのオペレーティングシステムの高速イーサネットと他のオペレーティングシステムの強制ギガビットの自動ネゴシエーションなど、さまざまなデータレート）。