Server ACK before Client ACK

ACK-TCP

asked 2021-08-25 09:35:51 +0000

Filip
1 ●1

During the analysing of a problem I had a situation where the Server sent an ACK before the Client even initiated the connection. Is this an error in Wireshark (Version 2.0.2 (v2.0.2-0-ga16e22e from master-2.0)) or is this due to some network configuration? Situation:

Timestamp 1: Server:389 -> Client->56469: [ACK] Seq=1Ack=1 Win=8207 Len=1[Malformed packet]
Timestamp 2: Client->56469 -> Server:389: [ACK] Seq=1Ack=2 Win=65335 Len=0 SLE=1 SRE=2
Timestamp 3: Client->56469 -> Server:389: [FIN, ACK] Seq=1Ack=2 Win=65335 Len=0
Timestamp 4: Server:389 -> Client->56469: [ACK] Seq=2Ack=2 Win=8207 Len=0
Timestamp 5: Server:389 -> Client->56469: [RST, ACK] Seq=2Ack=2 Win=0 Len=0

This happend when I started a LDAP connection from the client.

edit retag flag offensive close merge delete

Comments

There's no connection initiation in the text you provided. Sharing a Pcapng capture file through a publicly accessible file share site could go a long way.

Jaap ( 2021-08-25 16:13:20 +0000 )edit

The capture can be found for the next 7 days at: https://www.transfernow.net/dl/202108...

And indeed, it looks like the server reacted first although there was no communication before. The reason of my post is to understand it

Thanks.

Filip ( 2021-08-26 11:52:10 +0000 )edit

add a comment

answered 2021-08-27 13:43:27 +0000

Spooky

191 ●47 ●7 https://www.wireshark.org

Hi,

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.

JFD

edit flag offensive delete link

Comments

Before this capture there was no traffic from this client to this server. I have Apache Directory Studio installed and started the capture before I had configured this LDAP connection. This is why I found this strange.

Before this captured part, I made a connection to an other LDAP server, but I verified that there was no traffic to this server in the capture.

After this captured part, I see that there is a second attempt for this server which is working fine withall the packets in the right order.

A bit background: The whole as taken during an investigation of the LDAP/ADS servers behaviour. The DNS server returned multiple ip addresses and I was checking each one of them if the LDAP was working fine because we were experiencing connection failures. Wih this test I found out that one of the servers did not react.

Filip ( 2021-08-27 13:56:18 +0000 )edit

A TCP connection always begins with a 3-way handshake:

I find it unlikely that LDAP traffic over TCP would work without that initial TCP handshake. There could be an issue (option) with how your software filters traffic while capturing.

Nevertheless, glad you found the faulty server.

Spooky ( 2021-09-01 14:30:38 +0000 )edit

I agree that the traffic is probably, with first an action of the client, as it should be.

I was just wandering if this trace could be explained.

There are a lot of factors playing here, it is a VM-Ware server, IP v6 is disabled, in Wireshark the options resolved MAC Addresses and Show extra capture information dialog is enabled, and it is doubtfull that I can reproduce the issue. So I suspect there is no quick and easy answer to this question.

Thank you all for your insights and ideas.

Filip ( 2021-09-01 15:15:57 +0000 )edit

Allthough I thought to be sure there was not traffic before, all information I am getting, from you and my colleagues, is indicating that these packets are keep-alive packets of traffic that ran before. So the conclusion is that my understanding was wrong. Thank you for all the reactions, the thread can be closed.

Filip ( 2021-09-03 10:04:18 +0000 )edit

add a comment

Server ACK before Client ACK

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Server ACK before Client ACK edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Server ACK before Client ACK