したがって、 MANETネットワークのプロトコルスタックをデバッグするプロセスで、コンピューターとの無線ネットワークの修正されたTCPネットワーク接続がイーサネットゲートウェイを介してテストされ、サーバー側のクライアントによる接続を誤って閉じることにより、ソケットリソースを無限に長く保持できることが偶然明らかになりました！
これはすべてこれから始まりました。
スクリーンショットは、クライアント192.168.0.108（イーサネットゲートウェイ）とサーバー192.168.0.187（OS Windows Vista）の間のTCP接続を示しています。
ご覧のとおり、クライアントのFIN ACKパケットでシーケンス番号が誤って指定された場合、Windowsサーバーはソケットを閉じず、リソースを解放しませんでした。 同じクライアントポート（ソースポート40400）からサーバーポート（宛先ポート31000）に再度接続しようとして失敗しました。 サーバーは、クライアントからの新しいSYNに応じてACKを永続的に要求しました。
最初は、MANETスタック側のバグの一種（もちろん、FIN ACKの間違ったseqno）であると判断しましたが、シーケンス/確認応答番号でフローを分析し、他のポートで同じ実験を繰り返した後、はい、 Windows ...
別のサーバーポートの例（30000）：
その後、コンピューターを再起動し、すべてを再度繰り返しました。 今回はクライアントが接続を閉じ、サーバーはポート32000をリッスンしました。
結果は同じです。
それからnetstatチームはソケットの状態を見て、恐ろしくなりました...
サーバーは、何時間も自然界に存在しなかったソケットを開いたままにします!!!
そしておそらく、プロセスの強制終了または再起動のみが状況を救うでしょう。 明らかにFIN_WAIT_2状態では、Windowsにはソケット用のタイマーがなく、リソースをクリアするためにTIME_WAIT状態になりません。
まとめ
1.この脆弱性の人気を報告してください。
これが新しく発見されたバグである場合、Windows OSの多くのネットワーク製品が危険にさらされます。
2.他のサーバーとOS、主にLinuxでこの問題を調査することは興味深いでしょう。
3.ネットワークプロトコルを学ぶ！
PS
問題が発見されてから1日が経ちました-これまでにリソースが割り当てられました...