Sowmya Manjanatha <[email protected]> writes: > And, in fact, I did a wireshark tracing on the AD server. I see the > "TCP syn, syn-ack and then ack" all going through, a second later I see > a RST from the server but that is exactly after I see "abandoning > connection : Operation now in progress".
That network pattern (SYN, SYN-ACK, ACK, RST) sounds like the server is immediately (well, one second later) closing the TCP session after it is established. I'm not very familiar with the Windows side of things, but given the timing, that smells like a timeout on the server to me. It seems like the server got a connection from the client, but then the client didn't send any data after a second, and the server has a one second timeout on incoming connections. So it closes the connection. This could happen if, for example, packet loss causes the server to think the connection is established but the client never sees the completion of the handshake for some reason. But it didn't sound like that was consistent with the network packet trace you're seeing. It could also happen if the client data is being sent but lost, so the server never sees it, and that would be consistent with the trace output you had earlier. I'm not sure why your network would allow the TCP handshake through but not the actual data, though... a misconfigured firewall that is set up to accept handshakes but not data packets, maybe? Does the client send any data between the ACK and the RST? Or is the RST the very next packet that's sent after the ACK? It might be interesting to check both the client and the server. If the client thinks it sent data but the server never sees it, that would be a very useful data point. > My only guess now is that connect or write is taking much longer for > ipv6. Is there a way to wait for the Operation now in progress to go > away when we hit that. If the server is sending a RST, then the connection is dead and you won't be able to salvage it. That's a TCP close. The question now is why is the server closing the connection? And if it's because of a timeout, why is the client not sending any data? -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
