Random failure while communicating with KDC

Russ Allbery eagle at eyrie.org
Fri Feb 28 14:54:59 EST 2014


Sowmya Manjanatha <sowmya_ambale at yahoo.com> 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 (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>



More information about the Kerberos mailing list