TCP-соединение застряло в состоянии SYN_RECV, несмотря на получение ACK, Linux 2.6.18, встроенный, ARM

Мой клиент не может подключиться к моему порту протокола (TCP) после некоторых сбоев в работе сети, хотя все другие протоколы (telnet/HTTP/FTP) работают нормально.

netstat показывает, что мой сервер прослушивает, а tcpdump на сервере показывает, что все 3 пакета были обменены:

18: 29: 16.578964 IP 10.9.59.10.3355> 10.9.43.131.5084: S 2602965897: 2602965897 (0) выиграть 65535

18: 29: 16.579107 IP 10.9.43.131.5084> 10.9.59.10.3355: S 3464857909: 3464857909 (0) ack 2602965898 победа 5840

18: 29: 16,579284 IP 10.9.59.10.3355 > 10.9.43.131.5084: . 1 победа 65535

Но почему-то netstat -t показывает соединение по-прежнему в SYN_RECV, как будто ack не виден конечным автоматом TCP. Я должен перезагрузить свой сервер, чтобы заставить его работать.

syncookie не включен, и я знаю по поведению клиентского кода и tcpdump, что нет переполнения SYN.

Помощь высоко ценится.

2 ответа

Соединение находится в состоянии SYN_RECV, потому что ядро ​​получило пакет SYN для порта, который находится в режиме LISTENING, но другой конец не ответил ACK.

Проверьте, получен ли ACK сервером, запустив перехват на сервере. Захват сделан на клиенте или на сервере?

Это может произойти, если слушатель установил опцию DEFER_ACCEPT на сокете и еще не готов принять соединение.

Другие вопросы по тегам