0

I am very new at low level of TCP and I am tryingtcpdump with simple socket server and client program.

The server and client follow the two steps.

  1. Server and client make a connection.
  2. Client sends a string message.

The below is the output of tcpdump.

$ tcpdum -i lo

20:47:39.494935 IP localhost.38706 > localhost.5000: Flags [S], seq 2723581943, win 43690, options [mss 65495,sackOK,TS val 425070729 ecr 0,nop,wscale 7], length 0
20:47:39.494952 IP localhost.5000 > localhost.38706: Flags [S.], seq 2339154834, ack 2723581944, win 43690, options [mss 65495,sackOK,TS val 425070729 ecr 425070729,nop,wscale 7], length 0
20:47:39.494964 IP localhost.38706 > localhost.5000: Flags [.], ack 1, win 342, options [nop,nop,TS val 425070729 ecr 425070729], length 0 
20:47:49.471589 IP localhost.38706 > localhost.5000: Flags [P.], seq 1:5, ack 1, win 342, options [nop,nop,TS val 425073223 ecr 425070729], length 4
20:47:49.471625 IP localhost.5000 > localhost.38706: Flags [.], ack 5, win 342, options [nop,nop,TS val 425073223 ecr 425073223], length 0

The first three packets are for the handshake and next two packets are for client request message. However, I wonder why does client request packet contain ACK flag ([P.]), I think it is the first message for a request not having any packet to ACK.

I think ACK should mean that It receives some packet successfully. What is the ACK for in [P.] ( . is ACK in tcpdump)

1

It is acknowledging the SYN packet again.

In TCP the SYN and FIN bits are counted as a single byte as far as calculation of sequence numbers goes. And they are acknowledged pretty much the same. This is why you see ack 1 rather than ack 0.

In your flow the third packet acknowledges the SYN packet from the server to the client. And the fourth packet sending data from client to server acknowledges the SYN packet again.

Sending an ACK along in a packet carrying a payload does not cost extra bytes on the wire. The ACK bit is always in the header and just needs to be flipped from 0 to 1. The sequence number being acknowledged is also always there, but its value only has meaning if the ACK bit is 1.

From a quick inspection of traffic on my network it appears that the ACK bit is set on all TCP packets except from SYN and RST packets.

1
  • I think the question was primarily about your last sentence. On sender TCP data packets (not the first, which is ACKing the SYN), why is the ACK bit set on all of them? Is the sender ACKing every ACK from the receiver? Oct 7 '19 at 23:55

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