web-dev-qa-db-ja.com

TCP ACKを受信して​​も接続がSYN_RECV状態でスタックする、Linux 2.6.18、埋め込み、ARM

他のすべてのプロトコル（telnet/HTTP/FTP）が正常に機能しているにもかかわらず、ネットワーク障害が発生した後、クライアントがプロトコルポート（TCP）に接続できません。

netstatは私のサーバーがリッスンしていることを示し、サーバー上のtcpdumpは3つのパケットがすべて交換されたことを示しています。

18：29：16.578964 IP 10.9.59.10.3355> 10.9.43.131.5084：S 2602965897：2602965897（0）win 65535 <mss 1460、nop、nop、sackOK>

18：29：16.579107 IP 10.9.43.131.5084> 10.9.59.10.3355：S 3464857909：3464857909（0）ack 2602965898 win 5840 <mss 1460、nop、nop、sackOK>

18：29：16.579284 IP 10.9.59.10.3355> 10.9.43.131.5084：。 ack 1勝つ65535

しかし、どういうわけか、netstat -tは、TCP状態マシンによってackが表示されないかのように、SYN_RECVに接続を表示します。サーバーを再起動して機能させる必要があります。

syncookieが有効になっておらず、クライアントコードの動作とtcpdumpから、SYNフラッディングがないことがわかります。

どうぞよろしくお願いいたします。

linuxtcpconnectionsynchronization
3
waynix

これは、リスナーがソケットにDEFER_ACCEPTオプションを設定していて、まだ接続を受け入れる準備ができていない場合に発生する可能性があります。

3
Willy Tarreau

カーネルがLISTENINGモードのポートのSYNパケットを受信したが、もう一方の端がACKで応答しなかったため、接続はSYN_RECV状態にあります。

サーバーでキャプチャを実行して、ACKがサーバーによって受信されているかどうかを確認します。キャプチャはクライアントまたはサーバーのどちらで行われますか？

2
Mircea Vutcovici