Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a Java LDAP client making SSL connection to AD. Some times the connect hangs with client and server re-transmitting Client Key Exchange and ACK packets continuously as shown below and eventually times out after some 5 mins. Any possible explanation and solution for this behavior.

client ------ Client Key Exchange ----------------------> Server 
client ------ Client Key Exchange(Re-transmission)------> Server 
client <----- ACK --------------------------------------- Server   
client ------ Client Key Exchange(Re-transmission)------> Server 
client <------ Dup ACK --------------------------------- Server 
client ------ Client Key Exchange(Re-transmission)------> Server 
client <------ Dup ACK --------------------------------- Server

WireShark ScreenShot: http://img59.imageshack.us/img59/6431/p63e.png

share|improve this question
    
TCP-level ACK, or layer 7 ACK? The raw data would be much more useful here. –  BMDan Oct 14 '13 at 22:17
    
Its TCP ACK. I have verified SeqNum also. –  Anoop Oct 15 '13 at 9:07
    
Looks like the ACK isn't hitting the client. Is this an especially noisy, lossy, or slow connection? Again, the raw data is what is really needed here. –  BMDan Oct 15 '13 at 15:04
    
Packet capture is made from client. So client did recv ACK. If ACK failed to reach TCP layer, then this pattern can come. But I am not sure how that can happen after the packet reaches client. I will try to provide the raw data. –  Anoop Oct 16 '13 at 7:57
add comment

1 Answer

So, assuming that you are correct that the ACK is at a TCP level:

If the client is sent a TCP ACK, but continues to re-send the content which was ACK-ed, then it follows that the server has received and registered the content but the client has not received and registered the ACK.

Where are you collecting your data on the exchange? At the client, the server, or in between. You should probably collect at both ends, and as close to the ends as possible, so you can compare them to verify whether the problem is in the network (as seems likely).

Based on what you've told us, including that the ACKs fail to get through for an extended period, it seems unlikely that it's simple packet loss. I'd be looking very closely at configuration of any SSL tunnels or firewalls that are involved.

Can you collect and share tcpdump output from each end of the connection?

share|improve this answer
    
The packet trace is collected from client side. I will send screenshot of wireshark and dump. What are the cases where a ACK will not be registered by client. One other thing I noticed is that ACK and DupACK have SACK options. –  Anoop Oct 18 '13 at 10:44
    
I have attached wireshark screenshots. –  Anoop Oct 21 '13 at 13:22
    
given the round trip times, you are extremely close. I'm wondering if the client and server are even on separate physical hosts? Virtual networking brings in different possibilities. Or perhaps you're using some sort of tunnel, and the acks are from the near end of the tunnel? If you have a firewall installed on your client machine, be aware that tcpdump effectively captures packets on the outside of that firewall. –  mc0e Oct 23 '13 at 18:23
    
Client and Server are on separate hosts. Looks like the problem disappeared after removing a firewall in the network. But I am still curious as to how a TCP transaction can go in to this re transmit loop (as seen in wireshark screenshot) assuming there is a firewall in between. –  Anoop Oct 25 '13 at 5:14
1  
It's pretty simple. IF the client doesn't see the ack, then it assumes that it's last transmission didn't get through and it retransmits. Each time it re-transmits it waits a little longer before re-trying, and after a given number of tries it gives up. You'd see that the number of attempts and the timing would be consistent. –  mc0e Oct 25 '13 at 17:53
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.