Ask Your Question

Revision history [back]


From the 5 packets in the PCAP file, I can only offer some general analysis.

Is the connection between the server and LDAP server usually kept open (long live)?

If so, then there could be legitimate reasons for the server to send ACK to the client like for keepalive purposes.

If the client "initiated the connection" then, even from the application layer perspective, it is odd for the client to send a FIN/ACK.

The server does seem to respond appropriately ACKing the FIN/ACK from the client and then sending its own RST to close the TCP connection.

If the client wanted to do LDAP why did it close the TCP connection?

It is hard to tell if the client is actually reacting to the server ACK in frame 1.

To better troubleshoot this issue, try to capture the traffic from the TCP connection initiation (SYN, SYN/ACK, ACK) and keep the capture going until you have "the issue."

The packets that came before the server's ACK in frame 1 tells a story and will help you in your troubleshooting.

You might see those periodic TCP keepalive ACK and understand the timing of events better.

Hope this helps.