Random failure while communicating with KDC

[Sowmya Manjanatha]

Thanks again for your reply.  I gathered some more data per your suggestions.

From wireshark trace on the client also, client is not sending any data in between the ACK and RST.


I also did another experiment to figure out where RST gets issued.  


I added a scanf("%c", &ch) right before "try writing" i.e. before writev is invoked and right after.  On the first stop, I noticed that RST was not issued but the moment I hit a key and we stopped again where write just went through the RST was issued.  So, looks like the AD server is not happy about something we are writing.

What is being written here?   I am not quite familiar.  I have attached the wireshark traces from the client as bad3.cap, bad4.cap and bad5.cap

bad3.cap is up until only the connection to 445 is made, bad4.cap is at the first stop for input from keyboard i.e. write hadn't happened.
bad4.cap is right after the first keyboard input i.e. write happened but nothing else.
bad5.cap is the rest until it fails and gives up. 


-Sowmya.




On Friday, February 28, 2014 2:55 PM, Russ Allbery <eagle at eyrie.org> wrote:
 
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/
>