• 5

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191


File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

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

      • 1
    • 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.
    • 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.

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?

  • 0
Reply Report
      • 1
    • 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.
      • 1
    • 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.
      • 1
    • 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.
    • 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.

Trending Tags