Isso pode acontecer se o ouvinte tiver definido a opção DEFER_ACCEPT no soquete e ainda não estiver pronto para aceitar a conexão.
Meu cliente não pode se conectar à minha porta de protocolo (TCP) após alguns problemas de rede, mesmo que todos os outros protocolos (telnet / HTTP / FTP) funcionem bem.
netstat mostra que meu servidor está escutando e o tcpdump no servidor mostra todos os 3 pacotes trocados:
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 win 65535
Mas de alguma forma o netstat -t mostra a conexão ainda em SYN_RECV, como se o ack não fosse visto pela máquina de estados TCP. Tenho que reiniciar meu servidor para que ele funcione.
O syncookie não está ativado, e eu sei do comportamento do código do cliente e do tcpdump que não há inundação de SYN.
Ajuda muito apreciada.
Isso pode acontecer se o ouvinte tiver definido a opção DEFER_ACCEPT no soquete e ainda não estiver pronto para aceitar a conexão.
A conexão está no estado SYN_RECV porque o kernel recebeu um pacote SYN para uma porta que está no modo LISTENING, mas a outra extremidade não respondeu com o ACK.
Verifique se o ACK é recebido pelo servidor executando a captura no servidor. A captura é feita no cliente ou no servidor?